Git y Mercurial: ¿qué sería equivalente al flujo de trabajo de Git en Mercurial?

#lets get the latest 
git pull 

#lets switch to branch and do some work 
git checkout -b makeSomeBugs 

#do the work commit 
git add . 
git commit -am "introducing some bugs" 

#push this for my lazy remote friend to see 
git push origin makeSomeBugs 

#uh .. changes on master 
git pull origin master 

#do some work.. 
git commit -am "introducing some more bugs" 
git push origin makeSomeBugs 

#lets switch back to master 
git checkout master 
git pull 

#work is done, lets merge 
git merge --no-ff makeSomeBugs 
git push origin 

#and remove the branch to never ever see it again 
git push origin :makeSomeBugs 
git branch -d makeSomeBugs

Diversas fuentes de blogs (pero son bastante viejo) decir que la ramificación de este tipo en mercurial es no-go, en especial con la eliminación de la rama permanente ...Git y Mercurial: ¿qué sería equivalente al flujo de trabajo de Git en Mercurial?

Fuente

2012-04-24 gerasalus

He tratado y sin embargo, encontrar una manera de simular un flujo de trabajo en la rama git mercurial. La rama regular no funciona tímidamente porque no puede eliminarlos (solo ciérrelos, pero eso significa que el nombre de la rama se toma para siempre). Los marcadores se supone que son como las ramas de git, pero no parecen funcionar realmente como ellos, al menos para mí. – ryanzec

@ryanzec ¿Cómo te fallaron los marcadores? –

que podría tener algunos bits equivocada porque puede haber entendido mal GIT, pero asumiendo que usted está utilizando una versión reciente de Mercurial o si no, el bookmarks extension está activado ...

# lets get the latest 
# git pull 

hg pull 

# lets switch to branch and do some work 
# git checkout -b makeSomeBugs 

hg bookmark makeSomeBugs 

# do the work commit 
# git add . 
# git commit -am "introducing some bugs" 

hg commit -m "introducing some bugs" 

# push this for my lazy remote friend to see 
# git push origin makeSomeBugs 

hg push -B makeSomeBugs 

# uh .. changes on master 
# git pull origin master 

hg pull 
hg merge 

# do some work.. 
# git commit -am "introducing some more bugs" 
# git push origin makeSomeBugs 

hg commit -m "introducing some more bugs" 
hg push -B makeSomeBugs 

# lets switch back to master 
# git checkout master 
# git pull 

hg pull 
hg update -C <name of master rev> 

# work is done, lets merge 
# git merge --no-ff makeSomeBugs 
# git push origin 

hg merge makeSomeBugs 
hg push 

# and remove the branch to never ever see it again 
# (I assume you mean the label not the changesets) 
# git push origin :makeSomeBugs 
# git branch -d makeSomeBugs 

hg bookmark -d makeSomeBugs 
hg push -B makeSomeBugs

Hay un par de diferencias "modelo mental", pero yo creo que es bastante estrecha. El más grande es cuando borras el marcador. Lo eliminas localmente y luego presionas para que se elimine. Orden inverso de lo que hiciste con git.

También está la cuestión de lo que se utiliza para identificar la cabeza "maestro". Si había un marcador ya en el servidor para que (llamado master por ejemplo) la primera línea se convertiría en hg pull -B master, la primera fusión hg merge master y la actualización hg update -C master. Una vez que haya sacado un marcador la primera vez, cualquier extracción o impulso subsiguiente deberá actualizarlo sin necesidad de mencionarlo explícitamente.

Fuente

2012-04-25 08:08:58

Entonces, la pregunta es, ¿se puede ver en la historia que los cambios realizados en makeSomeBugs cuando se fusionan a los valores predeterminados y que se enviaron a origen siguen siendo visibles como cambios en makeSomeBugs? P.ej. ¿Puedo rastrear ese comit X y cometer Y se hicieron en makeSomeBugs después de la fusión? – gerasalus

@gerasalus: No, al igual que las ramas de Git, los marcadores no son permanentes. Las ramas con nombre son etiquetas permanentes y no tienen equivalente de Git. 'default' se refiere a la rama predeterminada * named *. No es lo mismo que 'maestro'. –

@PaulS: Ya no es necesario que habilite la extensión de marcadores hoy en día porque ahora se convirtió en una característica principal de Mercurial. –

Es más o menos lo mismo, excepto que con Mercurial por lo general, no me molestaría el nombramiento de su progreso en absoluto y sólo tiene que utilizar una rama en el anonimato.

Voy a dejar que se hunden en un momento ...

A diferencia de Git, Mercurial no 'olvidar' los conjuntos de cambios si no hay nombre de la sucursal o marcador asociado a él, así que no hay necesidad de nombrarlo y luego eliminarlo. Después de esto, se ve como un flujo de trabajo bastante estándar:

#lets get the latest 
hg pull 

#lets update to the latest and do some work 
hg update 

#do the work commit 
hg commit -Am "introducing some bugs" 

#serve this for my lazy remote friend to see 
hg serve 

#uh .. remote changes 
hg pull 

#do some work.. 
hg commit -Am "introducing some more bugs" 

#lets pull in the latest 
hg pull 

#work is done, lets merge 
hg merge 
hg push

Opcionalmente se puede utilizar un marcador si realmente desea mantener un registro de forma explícita la cabeza en el anonimato; cuando se inicia (después hg update), etiquetar el conjunto de cambios actual usando:

hg bookmark makeSomeBugs

Y cuando haya terminado (después de hg merge), eliminar el marcador usando:

hg bookmark -d makeSomeBugs

También podría empujar el marcador por el bien de tu amigo, pero ... meh.

Fuente

2012-04-25 08:14:15

Usted se está comprometiendo con el valor predeterminado, me estoy comprometiendo con la sucursal. Esto no es lo mismo. Como puedo crear otra rama desde el maestro y hacer cualquier otra cosa, no relacionada con la primera. – gerasalus

No, te estás comprometiendo con una nueva rama anónima, opcionalmente con un marcador. La ramificación ocurre cada vez que la línea de compromisos diverge. Si quiere comprometerse con algo más que el nombre 'predeterminado', entonces necesita hacer otra rama * nombrada *. Estás golpeando un obstáculo cultural aquí: usar ramas anónimas es común en Mercurial, mientras que es bastante imposible en Git. Las ramas con nombre son permanentes y deben establecerse con anticipación; si desea rastrear esa rama anónima, usa un marcador. –

En Mercurial, las ramas con nombre son permanentes y, por lo general, se utilizan para rastrear las entregas. Puede usarlos para rastrear características también, pero generalmente el trabajo de la característica se realiza en sucursales anónimas. Los marcadores se pueden usar opcionalmente para seguir el trabajo en sucursales anónimas. Esto es útil si está trabajando en varias cosas a la vez o el código necesita ser compartido antes de fusionarlo de nuevo. –

Git y Mercurial: ¿qué sería equivalente al flujo de trabajo de Git en Mercurial?

Respuesta

Cuestiones relacionadas