¿Cuál es la mejor manera (y la más segura) de fusionar una rama de Git con la maestra?

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:

1. Es inseguro, porque no sabemos si hay conflictos entre la rama de pruebas y la rama maestra.

2. 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:

• si no está seguro de las operaciones de rebasamiento, consulte: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

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.