dvcs: ¿es "clonar para ramificar" un flujo de trabajo común?

9

Recientemente estuve discutiendo sobre dvcs con un compañero de trabajo, porque nuestra oficina está comenzando a considerar cambiar de TFS (somos una tienda de MS). En el proceso, me confundí mucho porque dijo que aunque usa Mercurial, no había oído hablar de un comando de "rama" o "pago", y estos términos no le eran familiares. Después de preguntarse cómo era posible que él no supiera sobre ellos y explicar cómo las ramas dvcs funcionan "en su lugar" en sus archivos locales, estaba bastante confundido.

Explicó que, de manera similar a cómo funciona TFS, cuando quiere crear una "rama" lo hace mediante la clonación, por lo que tiene una copia completa de su repositorio. Esto me pareció realmente extraño, pero el beneficio, que tengo que reconocer, es que puedes mirar o trabajar en dos ramas simultáneamente porque los archivos están separados.

Al buscar en este sitio para ver si esto se ha preguntado antes, vi un comentario de que muchos recursos en línea promueven esta metodología de "clonar para ramificar", para consternación del afiche. ¿Es esto realmente común en la comunidad dvcs? ¿Y cuáles son algunos de los pros y los contras de ir de esta manera? Nunca lo haría, ya que no necesito ver varias ramas a la vez, el cambio es rápido y no necesito que todos los clones llenen mi disco.

workflows dvcs branching

— Tesserex
fuente

77

esto es una retención de los flujos de trabajo de CVS y SVN, recuerde "para un martillo todo parece un clavo"

1

@JarrodRoberson: solo si te limitas a la forma en que gitfunciona. Con hgeste suele ser el primer flujo de trabajo enseñó y todavía es muy útil.

— Mark Booth

3

Además de la ventaja / desventaja general de poder ver ambas ramas, creo que hay una ventaja específica de Mercurial para hacerlo.

Si clona para crear una rama, puede eliminar el clon más adelante si no desea conservar sus cambios. Si decide fusionarlos, el hecho de que decidió separar sus cambios de esta manera no es visible para nadie más.

Por el contrario, si usa hg branchpara crear una nueva rama con nombre, el nombre de la rama se registra en el historial cuando se compromete, es visible para todos los demás y debe ser bastante único para evitar posibles confusiones más adelante. Esto podría no ser apropiado si su rama es para desarrollar alguna característica experimental, o para un cambio que podría resultar pequeño.

Si usa ramas con nombre para mantener versiones lanzadas de su software y también las usa para desarrollar características a corto plazo o correcciones de errores, es fácil confundirse porque no hay forma (además de las convenciones de nombres) de mantener estos dos tipos de ramas separadas.

http://mercurial.selenic.com/wiki/StandardBranching explica esto con más detalle. También vale la pena mencionar que desde Mercurial 1.8, es posible crear un marcador ( hg bookmark), un nombre desechable para una sucursal de corta duración. Los marcadores se pueden empujar, tirar, mover y eliminar.

— benj
fuente

2

No he usado mucho Mercurial pero Git no tiene este problema. Puedo ramificar todo el día localmente, fusionarme en desarrollar sucursal, presionar y nadie tiene que mirar los nombres de mis sucursales.

— Andrew T Finnell

3

@AndrewFinnell: Realmente no encajaba en la pregunta, pero quería decir que no es necesariamente un problema, también hay algunas ventajas en la forma en que se nombran las ramas en el trabajo de Mercurial. Por ejemplo, puede ver en qué rama se realizó originalmente una confirmación, que puede ser útil saber.

— benj

1

@AndrewFinnell: las ramas con nombre son algo que realmente extraño git, ya que me he acostumbrado a ellas hg. Además, tener que recordar explícitamente git branchcada vez que quiero crear una rama es molesto, en comparación con hgla creación automática de ramas sin nombre.

— Mark Booth

Todavía puede usar la extensión de banda incluida para eliminar su rama en hg. Mercurial admite mejor la modificación del historial en estos días mediante el uso de "fases"

— dukeofgaming

2

Cada vez que se compromete en un DVCS técnicamente está haciendo una bifurcación en la historia, cada vez que lo devuelve al bendito repositorio lo integra de nuevo, aquí viene la parte interesante:

Si nadie realizó un cambio durante su confirmación, no se verá como una rama en el DAG (gráfico acíclico dirigido)
Si alguien más realizó un cambio durante su confirmación, se verá como una rama en el DAG, solo sin nombre

¿Recuerda el botón "bifurcación" en Bitbucket / github ?, bifurcación puede considerarse como un sinónimo de ramificación, y lo que hace el botón "bifurcación" es solo un clon de ese repositorio en su cuenta.

La única ventaja de "clonar en rama" es poder trabajar simultáneamente en dos puntos de la historia, e irónicamente para su compañero de trabajo, es un flujo de trabajo común para trabajar en diferentes ramas al mismo tiempo (sin tener que ir y venir) )

Dígale a su compañero de trabajo que aprenda a ramificarse , es muy fácil, aquí tiene un tutorial:

D:\>mkdir lol

D:\>cd lol

D:\lol>hg init

D:\lol>hg branch
default

D:\lol>touch lol

D:\lol>hg add lol

D:\lol>hg commit -m "lol"

D:\lol>hg branch lol
marked working directory as branch lol
(branches are permanent and global, did you want a bookmark?)

D:\lol>hg branches
default                        0:35d562fafaf2

D:\lol>echo "lol" > lol

D:\lol>hg commit -m "New lol branch"

D:\lol>hg branches
lol                            1:9384f923e78d
default                        0:35d562fafaf2 (inactive)

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg update lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg merge lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

D:\lol>hg commit -m "lol merge"

D:\lol>hg branch
default

D:\lol>hg update lol
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

"Clonar en rama" tiene sentido cuando trabaja en diferentes ramas al mismo tiempo , o cuando desea probar un experimento sin crear una rama permanente en el historial y aún así poder volver a integrarlo en una rama ya existente .

Personalmente no me gusta esta práctica y prefiero hacer sucursales y cerrarlas si es necesario. Aquí, así es como lo haces:

D:\lol>hg branches
default                        2:46420aca1612
lol                            1:9384f923e78d (inactive)

D:\lol>hg branch
lol

D:\lol>hg commit --close-branch -m "Obai, glorious lol branch"

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branch
lol

D:\lol>hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branches --closed
default                        2:46420aca1612
lol                            3:4b79c577e029 (closed)

Espero que esto aclare sus dudas de ramificación DVCS, aquí las ramas ya no dan miedo.

— dukeofgaming
fuente

0

Personalmente, no me preocuparía por el código que llena mi disco ... primero, es solo código, y segundo, no vas a mantener todos tus clones para siempre.

Esta metodología se promueve en muchos recursos en línea, especialmente para Hg. Nunca lo he visto usado en producción, en entornos de CI es mucho más común tener ramas de características de corta duración que clones de repositorio adicionales. No veo la ventaja de hacer esto, en todo caso hará que su historia sea más confusa, no menos, y tampoco le dará nada. Si desea ver su nuevo código junto con el código anterior, puede usar una herramienta de diferencia / fusión para ver las dos confirmaciones una al lado de la otra, con la ventaja adicional de que verá sus cambios resaltados.

— filosodad
fuente

Lo he usado ampliamente en producción, con hg. Poder empujar y tirar entre múltiples hgrepositorios puede ser una herramienta de colaboración realmente poderosa. Solo poder extraer de gitrepositorios no desnudos puede limitar sustancialmente sus opciones con este tipo de flujo de trabajo.

— Mark Booth