git rebase en actualizaciones remotas

Question

Trabajo con un equipo pequeño que usa git para la administración de código fuente. Recientemente, hemos estado haciendo ramas de temas para hacer un seguimiento de las características y luego fusionarlas en el maestro localmente y luego enviarlas a un repositorio central de git en un servidor remoto. Esto funciona muy bien cuando no se han realizado cambios en el maestro: creo mi rama de tema, la comprometo, la fusiono en maestro y luego la presiono. Hurra.

Sin embargo, si alguien ha enviado a origen antes que yo, mis confirmaciones no son rápidas. Por lo tanto, se produce un compromiso de fusión. Esto también ocurre cuando una rama de tema debe fusionarse con el maestro localmente para garantizar que mis cambios funcionen con el código a partir de ahora. Por lo tanto, terminamos con confluencias de fusión en todas partes y un registro de git que rivaliza con un brazalete de amistad.

Por lo tanto, el rebase es la opción obvia. Lo que me gustaría es:

• crear ramas puntuales que sostiene varias entregas
• checkout master y tire (avance rápido porque no he cometido para dominar)
• ramas puntuales rebase en el nuevo jefe de dominar
• rebase los temas contra el maestro (por lo que los temas a empezar por la cabeza maestros), con lo que amo a mi tema cabeza

mi forma de hacer esto actualmente se enumeran a continuación:

git checkout master 
git rebase master topic_1 
git rebase topic_1 topic_2 
git checkout master 
git rebase topic_2 
git branch -d topic_1 topic_2 

¿Hay una forma más rápida de hacerlo?

Answer 1

he encontrado, con el tiempo, mi solución favorita es:

git checkout topic 
# make [n] commits 
git rebase -i HEAD~[n] #clean up time 
git checkout master 
git pull --rebase 
git checkout topic 
git rebase master 
git checkout master 
git merge topic 
git push origin 

Answer 2

Para nuestro equipo, configuramos algo que funciona muy bien y no utiliza rebase en absoluto.

Recortamos nuestro trabajo en las entradas de Jira que no tardan demasiado, por lo general 1-2 días de esfuerzo. Cada desarrollador crea una rama por boleto y trabaja en esta rama. Cuando esté listo para compartir esto, se envía al servidor central.

El servidor central es supervisado por un servidor hudson CI que extrae los cambios, fusiona todas las ramas actualizadas, reconstruye el software, ejecuta las pruebas y lo envía todo al repositorio principal central de git.

A partir de ahí lo llevamos de vuelta a nuestros repositorios. Hacemos regularmente (es decir, cada dos días) fusionar nuestras ramas de trabajo con el maestro central para mantenerlas "cerca".

Dado que nadie está trabajando en la máquina 'fusionando' y nadie más que el servidor de CI toca el maestro, tenemos problemas de fusión muy poco frecuentes (en aproximadamente el 1-2% de las confirmaciones). Y estos se resuelven rápidamente en el servidor de compilación al limpiar el espacio de trabajo. Descubrimos que podríamos haber evitado la mayoría de estas manteniendo cortas las ramas y fusionándonos con el maestro remoto antes de presionar.

También me gusta que la fusión sea mucho más robusta que el rebasado y requiera mucha menos repetición.

Answer 3

¿Conoce git pull --rebase? Se rebases en lugar de fusionarse cuando tiras, y evita que los commits de fusión contaminen tu historial.

También puede configurarlo como el comportamiento predeterminado para una rama con las opciones de configuración branch.<name>.rebase y branch.autosetuprebase.

Answer 4

También se puede simplemente rebase en contra de la puesta al día maestro

git checkout topic_1 
git rebase refs/remotes/origin/master 

que obvia la necesidad de que el tirón (al menos hasta el EOL de su rama de características). Nuestro proceso utiliza las solicitudes de extracción de GitHub, por lo que nunca tendré que hacerlo localmente.