¿Viene de mercurial a git – fusionarse?

He usado mercurial durante bastante time y ahora cambié a git, porque mi nuevo equipo lo usa como herramienta de control de versiones pnetworkingeterminada.

Déjame explicarte: en el proyecto mercurial I clone de Bitbucket, realizo algunos cambios en el proyecto. Luego saco bitbucket de nuevo y fusiono mis cambios con todo lo que ha cambiado en bitbucket. Entonces empujo todo.

¿Funciona igual con git? Hice un proyecto clonado, realicé algunos cambios, hice algunos commits con ellos, ahora saqué proyecto y quiero unirme. Estos pasos previos funcionan bien, pero la fusión es un poco diferente o al less me parece diferente. ¿Cómo fusiono mis confirmaciones con las nuevas confirmaciones que acabo de retirar del server?

PD: mis cambios y cambios en el server se han realizado en la twig principal, no estoy buscando fusionar 2 twigs.

Mi comprensión de esto, viniendo como un compañero usuario de Mercurial, es que en Git todas las cabezas deben tener nombres únicos. Por lo tanto, no creará una nueva cabeza a less que le dé un nuevo nombre. Entonces en Mercurial puedes hacer esto:

hg pull / git pull hg commit / git commit hg commit / git commit ----B----C1----C2 

Donde B es la revisión base que originalmente sacó, y C1 y C2 son sus cambios. A continuación, extrae las actualizaciones del server.

 hg pull ----B----C1----C2 \ ----o----o----o 

Git no hará esto, ya que habría tenido que crear otra cabeza. Por lo tanto, tiene que volver a establecer / injertar sus cambios en la parte superior de los serveres.

 git pull --rebase ----B----o----o----o----C1----C2 

La alternativa es cuando comienzas tu trabajo en Git creas un nombre para tu cabeza. Git lo llama una twig, Hg lo llama marcador.

 hg pull / git pull hg bookmark / git branch hg commit / git commit hg commit / git commit ----B----C1----C2 ^ New-Feature 

Ahora la cabeza tiene un nombre ("Nueva function" en este caso). Ahora Git felizmente va a tirar, al igual que Hg.

 hg pull / git pull ----B----C1----C2 \ ^ New-Feature ----o----o----o 

Luego puedes unirte de la misma manera.

 git pull --rebase origin master 

inserta cambios y acumula sus cambios locales en la parte superior.

Sin embargo, crear twigs para cada característica nueva es el flujo de trabajo previsto para Git, por lo que es posible que desee aprender sobre ellas de todos modos. La ramificación y fusión rápidas es la característica principal de Git.

Mi consejo es mantenerse alejado de git rebase / pull –rebase hasta que te sientas cómodo con las twigs de git. Ahora, lo más importante que estoy sorprendido, nadie ha mencionado aún:

hg pull solo obtiene nuevos sets de cambios para su repository local y no afecta su copy de trabajo.

git pull obtiene nuevas confirmaciones e intenta fusionar automáticamente la HEAD recién sacada con tu HEAD local. Si no ha confirmado los cambios, podría causarle algunos problemas.

Solución: al less por ahora, siempre use git fetch. Esto no afecta su copy de trabajo y le permite fusionarse en su propio time, como con Mercurial. En otras palabras, git fetch = hg pull.

Puede afirmar que no tiene la intención de fusionar dos twigs, pero fundamentalmente lo es.

Considere el estado inicial: tenemos dos cabezas, master y origin/master que ambos apuntan a cometer A Luego, alguien agrega los commit B y C y los empuja al control remoto de origin que usted fetch . Sin embargo, antes de search, usted ha agregado D , E y F a su twig master , por lo que después de la fetch el layout de DAG se ve así:

 A -> B -> C [origin/master] | \--> D -> E -> F [master] 

Y desea enviar sus cambios al repository de origin . Pero sus cambios entran claramente en conflicto con la twig de origin/master , para hacer esto, debería fusionar origin/master y master .

Tener muchas fusiones puede ser feo, así que bajo algunas condiciones importantes podemos realizar una rebase en su lugar. Sin embargo, debe tener cuidado: no puede haber llevado estos cambios a ningún otro repository externo ni nada por el estilo, o romperá cualquier otra cosa que esté basada en estos commits. Tampoco tendría nada más basado en tu master actual, porque esos commits ahora estarán desactualizados.

Por lo tanto, tienes dos opciones:

  • Fusionar origin/master en master : git merge origin/master && git push origin master
  • Rebase master en origin/master : git rebase origin/master && git push origin master

Ambos pueden combinarse con git-fetch para crear git-pull , que usará automáticamente el método de fusión a less que proporciones la opción --rebase , en cuyo caso realiza una rebase .

Solo recuerde tener cuidado con usar siempre --rebase debido a la naturaleza del command rebase .

Estado final después de usar una fusión:

 A -> B -> C -----> G | | \--> D -> E -> F ---- 

Estado final después de usar una rebase:

 A -> B -> C -> D -> E -> F