Pregunta La mejor (y más segura) forma de fusionar una rama git en master


Una nueva rama de master se crea, lo llamamos test.

Hay varios desarrolladores que se comprometen a master o crear otras ramas y luego fusionarse en master.

Digamos trabajo en test está tomando varios días y desea mantener continuamente test actualizado con commits dentro master.

yo lo haría git pull origin master de test.

Pregunta 1: ¿Es este el enfoque correcto? Otros desarrolladores podrían haber trabajado fácilmente en los mismos archivos que he trabajado por cierto.


Mi trabajo en test está hecho y estoy listo para fusionarlo de nuevo a master. Estas son las dos formas en que puedo pensar:

UN: 

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

SEGUNDO: 

git checkout test
git pull origin master
git checkout master
git merge test

No estoy usando --rebase porque desde mi entendimiento, rebase obtendrá los cambios de master y apilar el mío además de eso, podría sobrescribir los cambios que otras personas hicieron.

Pregunta 2: ¿Cuál de estos dos métodos es el correcto? ¿Cuál es la diferencia allí?

El objetivo en todo esto es mantener mi test rama actualizada con las cosas que suceden en master y más tarde podría fusionarlos de nuevo en master esperando mantener la línea de tiempo lo más lineal posible.


1463
2018-04-09 00:01


origen


Respuestas:


Cómo haría esto

git checkout master
git pull origin master
git merge test
git push origin master

Si tengo una sucursal local desde una remota, no me siento cómodo fusionando otras sucursales que esta con el control remoto. Además, no presionaría mis cambios, hasta que esté satisfecho con lo que deseo impulsar y también no impulsaría las cosas, solo para mí y mi repositorio local. En tu descripción, parece que test es solo para ti? Entonces no hay razón para publicarlo.

git siempre trata de respetar el tuyo y los demás cambios, y también lo hará --rebase. No creo poder explicarlo adecuadamente, así que eche un vistazo a el libro de Git - Rebase o git-ready: Introducción al rebase para una pequeña descripción. Es una característica bastante genial


2158
2018-04-09 00:45



Esta es una pregunta muy práctica, pero todas las respuestas anteriores no son prácticas.

Me gusta

git checkout master
git pull origin master
git merge test
git push origin master

Este enfoque tiene dos cuestiones:

  1. No es seguro, porque no sabemos si hay algún conflicto entre la rama de prueba y la rama principal.

  2. "Exprimiría" todas las confirmaciones de prueba en una confesión de fusión en el maestro; es decir, en la rama principal, no podemos ver todos los registros de cambios de la rama de prueba.

Entonces, cuando sospechamos que habría algunos conflictos, podemos tener las siguientes operaciones de git:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Prueba merge antes de commit, evitar un compromiso de avance rápido por --no-ff,

Si se encuentra un conflicto, podemos ejecutar git status para verificar detalles sobre los conflictos y tratar de resolver

git status

Una vez que resolvemos los conflictos, o si no hay conflicto, commit y push ellos

git commit -m 'merge test branch'
git push

Pero de esta manera perderá el historial de cambios registrado en la rama de prueba, y haría que la rama maestra fuera difícil para otros desarrolladores comprender el historial del proyecto.

Entonces, el mejor método es que debemos usar rebase en lugar de merge (supongamos, cuando en este momento, hemos resuelto los conflictos de rama).

La siguiente es una muestra simple, para operaciones avanzadas, consulte http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Sí, cuando hayas hecho la parte superior, todas las confirmaciones de la rama de prueba se moverán al jefe de la rama principal. El principal beneficio de rebasar es que obtienes un historial de proyecto lineal y mucho más limpio.

Lo único que debe evitar es: nunca use rebase en la rama pública, como la rama principal.

como la siguiente operación:

git checkout master
git rebase -i test

nunca hagas estas operaciones.

Detalles para https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

apéndice:


260
2018-03-14 12:13



Ni una rebase ni una fusión deberían sobrescribir los cambios de nadie (a menos que decida hacerlo al resolver un conflicto).

El enfoque habitual durante el desarrollo es

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

Cuando esté listo para fusionarse de nuevo en el maestro,

git checkout master
git log ..test # if you're curious
git merge test
git push

Si te preocupa romper algo en la fusión, git merge --abort está ahí para ti.

Usar "push" y "pull" como medio de fusión es una tontería. Tampoco estoy seguro de por qué estás presionando la prueba de origen.


73
2018-04-10 00:17



Además KingCrunches respuesta, Sugiero usar

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

Es posible que haya realizado muchas confirmaciones en la otra rama, que solo debería ser una confirmación en la rama principal. Para mantener el historial de confirmaciones lo más limpio posible, es posible que desee aplastar todas las confirmaciones de la rama de prueba en una confirmación en la rama maestra (consulte también: Git: ¿aplastar o no aplastar?) Entonces también puede reescribir el mensaje de compromiso a algo muy expresivo. Algo que es fácil de leer y entender, sin profundizar en el código.

editar: puede interesarte

Así que en GitHub, termino haciendo lo siguiente para una rama de características mybranch:

Obtenga lo último del origen

$ git checkout master
$ git pull origin master

Encuentra el hash de base de combinación:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Ahora asegúrate de que solo el primero pick, el resto es s:

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Luego elige un mensaje de confirmación muy bueno y presiona a GitHub. Haga la solicitud de extracción entonces.

Después de la fusión de la solicitud de extracción, puede eliminarla localmente:

$ git branch -d mybranch

y en GitHub

$ git push origin :mybranch

20
2018-04-21 08:18



Este es el flujo de trabajo que utilizo en mi trabajo con el equipo. El escenario es como lo describiste. Primero, cuando termine de trabajar en test Rebase con el maestro para extraer todo lo que se ha agregado al maestro durante el tiempo que he estado trabajando en el test rama.

git pull -r upstream master

Esto hará que los cambios se vuelvan maestros, ya que bifurcó el test bifurcar y aplicarlos, y luego aplicar los cambios que ha realizado para probar "sobre el estado actual de maestro". Puede haber conflictos aquí, si las otras personas han realizado cambios en los mismos archivos que ha editado en la prueba. Si los hay, tendrá que arreglarlos manualmente y confirmarlos. Una vez que hayas hecho eso, serás bueno para cambiar a la rama principal y fusionar testadentro sin problemas


3
2018-03-16 22:27



git checkout master
git pull origin master
# Merge branch test into master
git merge test

Después de la fusión, si el archivo se cambia, al fusionarlo se producirá un error de "Resolver el conflicto".

Entonces, primero necesitas resolver todos tus conflictos, debes volver a cometer todos tus cambios y luego presionar

git push origin master

Esto es mejor hacer quién ha hecho los cambios en la rama de prueba, porque él sabía qué cambios ha hecho.


1
2018-04-07 08:55