Se crea una nueva rama desde master
, la llamamos test
.
Hay varios desarrolladores que se comprometen con master
o crean otras ramas y posteriormente se fusionan con master
.
Digamos que el trabajo en test
lleva varios días y se quiere mantener continuamente actualizada test
con commits dentro de master
.
Yo haría git pull origin master
desde test
.
Pregunta 1: ¿Es este el enfoque correcto? Otros desarrolladores podrían haber trabajado fácilmente en los mismos archivos que yo he trabajado btw.
Mi trabajo en test
está hecho y estoy listo para fusionarlo de nuevo con master
. Estas son las dos formas que se me ocurren:
A:
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test
B:
git checkout test
git pull origin master
git checkout master
git merge test
No estoy usando --rebase
porque desde mi punto de vista, rebase obtendrá los cambios de master
y apilará los míos encima de eso, por lo que 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?
El objetivo de todo esto es mantener mi rama test
actualizada con las cosas que suceden en master
y más tarde podría fusionarlas de nuevo en master
con la esperanza de mantener la línea de tiempo lo más lineal posible.
Cómo lo haría yo
git checkout master
git pull origin master
git merge test
git push origin master
Si tengo una rama local de una remota, no me siento cómodo con fusionar otras ramas que no sean esta con la remota. Además no empujaría mis cambios, hasta que esté contento con lo que quiero empujar y también no empujaría cosas en absoluto, que son sólo para mí y mi repositorio local. En tu descripción parece que la "prueba" es sólo para ti. Así que no hay razón para publicarlo.
git siempre intenta respetar tus cambios y los de los demás, y así lo hará --rebase
. No creo que pueda explicarlo adecuadamente, así que echa un vistazo a el libro de Git - Rebasing o git-ready: Intro into rebasing para una pequeña descripción. Es una característica muy interesante
Esta es una pregunta muy práctica, pero todas las respuestas anteriores no son prácticas.
Como
git checkout master
git pull origin master
git merge test
git push origin master
Este enfoque tiene dos problemas:
Es inseguro, porque no sabemos si hay conflictos entre la rama de pruebas y la rama maestra.
Es decir, en la rama maestra, no podemos ver todos los registros de cambio de la rama de prueba.
Por lo tanto, cuando sospechamos que hay algunos conflictos, podemos tener las siguientes operaciones git:
git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test
Probar merge
antes de commit
, evitar un commit rápido por --no-ff
,
Si se encuentra un conflicto, podemos ejecutar git status
para comprobar los detalles de los conflictos y tratar de resolverlos
git status
Una vez que resolvemos los conflictos, o si no hay conflicto, commit
y push
.
git commit -m 'merge test branch'
git push
Pero de esta manera se perderá la historia de los cambios registrados en la rama de prueba, y haría que la rama maestra sea difícil para otros desarrolladores entender la historia del proyecto.
Así que el mejor método es que tenemos que utilizar rebase
en lugar de merge
(supongamos, cuando en este momento, hemos resuelto los conflictos de rama).
A continuación se muestra un ejemplo simple, para las operaciones avanzadas, por favor, 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 tengas los uppers hechos, todos los commits de la rama Test se moverán a la cabeza de la rama Master. El mayor beneficio de rebasar es que se obtiene una historia del proyecto lineal y mucho más limpia.
Lo único que debes evitar es: no usar nunca rebase
en una rama pública, como la rama maestra.
Nunca hagas operaciones como las siguientes:
git checkout master
git rebase -i test
Detalles para https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing
apéndice:
Ni un rebase ni una fusión deben 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 fusionar 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 luego pull como medio de fusión es una tontería. Tampoco estoy seguro de por qué usted está empujando la prueba de origen.