¿Cómo puedo usar git rebase sin requerir un empuje forzado?

En un intento por lograr git nirvana, me paso el día aprendiendo cómo aprovechar el rebase para situaciones en las que actualmente me fusiono.

Al ejecutar lo que considero un flujo de git 101 (que deletreo a continuación), tengo que hacerlo push --forcecuando empujo mis cambios al origen.

No soy el único, sé que este es un terreno cubierto (ver 1 , 2 , 3 , 4 , 5 ) y entiendo las razones técnicas por las que es necesaria una fuerza. Mi problema es este: hay muchas (muchas) entradas de blog que alaban a rebase y cómo ha cambiado sus vidas (ver 1 , 2 , 3 , 4 para enumerar algunas), pero ninguna de ellas menciona que push --forcees parte de su flujo. Sin embargo, casi todas las respuestas a las preguntas de stackoverflow existentes dicen cosas como "sí, si vas a rebasar, debes usar push --force".

Dado el número y la religiosidad de los defensores del rebase, tengo que creer que usar 'empujar - fuerza' no es una parte inherente de un flujo de rebase, y que si uno a menudo tiene que forzar sus empujes, está haciendo algo mal .

push --forcees algo malo .

Así que aquí está mi flujo. ¿De qué manera podría lograr los mismos resultados sin una fuerza?

Ejemplo simple

Dos ramas:

• v1.0 - una rama de lanzamiento, contiene solo parches
• master : todo para la próxima versión principal.

Tengo algunas confirmaciones de parches y algunas confirmaciones para la próxima versión.

Me gustaría incorporar los parches a mi master para que no se pierdan para el próximo lanzamiento. Pre-iluminación Yo simplemente:

git checkout master
git merge v1.0

Pero ahora lo estoy intentando

git checkout master
git rebase v1.0

Así que ahora estoy aquí:

Tiempo para:

git push

No dados.

Rebasing es una gran herramienta, pero funciona mejor cuando la usas para crear fusiones de avance rápido para ramas de temas en master. Por ejemplo, puede cambiar la base de su rama add-new-widget contra master:

git checkout add-new-widget
git rebase -i master

antes de realizar una combinación de avance rápido de la rama en master. Por ejemplo:

git checkout master
git merge --ff-only add-new-widget

El beneficio de esto es que su historial no tendrá muchas confirmaciones de fusión complejas o conflictos de fusión, porque todos sus cambios se volverán a basar en la punta del maestro antes de la fusión. Un beneficio secundario es que ha cambiado de base, pero no tiene que usarlo git push --forceporque no está superando el historial en la rama maestra.

Ciertamente, ese no es el único caso de uso de rebase, o el único flujo de trabajo, pero es uno de los usos más sensibles que he visto. YMMV.

@CodeGnome tiene razón. No debe rebasar el maestro en la rama v1.0 sino la rama v1.0 en el maestro, eso hará toda la diferencia.

git checkout -b integrate_patches v1.0
git rebase master
git checkout master
git merge integrate_patches

Cree una nueva rama que apunte a v1.0, mueva esa nueva rama encima de la maestra y luego integre la nueva versión de los parches de la V1.0 a la rama maestra. Terminarás con algo como:

o [master] [integrate_patches] Another patch on v1.0
o A patch on v1.0
o Another change for the next major release
o Working on the next major release
|  o [v1.0] Another path on v1.0
|  o A patch on v1.0
| /
o Time for the release

Esta forma de usar rebase es recomendada por la documentación oficial de git .

Creo que tienes razón git push --force: solo debes usarlo si cometiste un error y presionaste algo que no querías.

Tienes que forzar el empuje si vuelves a basar, y ya has publicado tus cambios, ¿verdad?

Utilizo rebase mucho, pero publico en algo privado donde un impulso forzado no importa (por ejemplo: mi propio clon en GitHub, como parte de una solicitud de extracción), o realizo un cambio de base antes de presionar por primera vez.

Este es el corazón del flujo de trabajo donde usa rebase, pero no fuerce el empuje mucho: no publique cosas hasta que estén listas, no rebase después de empujar.

Creo que hay un buen caso de uso para este patrón de rebase-luego-force-push que no es el resultado de un empujón equivocado: trabajar en una rama de función usted mismo desde múltiples ubicaciones (computadoras). Hago esto a menudo, ya que a veces trabajo en la oficina en mi escritorio y, a veces, desde mi casa / sitio del cliente en mi computadora portátil. Necesito reajustar ocasionalmente para mantenerme al día con la rama principal y / o hacer fusiones más limpias, pero también necesito forzar cuando dejo una máquina para ir a trabajar en otra (donde solo tiro). Funciona a las mil maravillas, siempre que sea el único que trabaje en la sucursal.

Esto es lo que uso (asumiendo que el nombre de su rama es foobar ):

git checkout master              # switch to master
git rebase   foobar              # rebase with branch
git merge -s ours origin/master  # do a basic merge -- but this should be empty
git push origin master           # aaand this should work

tl; dr fusionar con ramas compartidas, rebase con ramas individuales. --force-with-leasees una alternativa más segura a la fuerza y ​​debería ayudarlo a lograr dicho nirvana git sin la naturaleza destructiva de la fuerza.

Una regla general que he visto que funciona para los flujos de trabajo de varios equipos es usarla mergepara ramas compartidas (es decir, master o desarrollar) y usarla rebasecuando se trabaja en su propia rama de funciones. Este es un ciclo de vida típico de una rama de características

git checkout master
git checkout -b new-feature
git commit -am "commit new work"
git push -u origin new-feature
# have code reviewed, run CI, etc.,
# meanwhile master has new commits
git checkout master
git pull
git rebase -i master # -i for interactive rebase allows you to squash intermediate commits
git push --force-with-lease
git merge master

Una versión en inglés simple de lo que hemos hecho aquí:

1. Creó una nueva rama fuera del maestro
2. Trabajo realizado en la rama y empujado a control remoto
3. rebasado en el maestro
4. Empuje el trabajo a control remoto con force-with-lease
5. fusionar en maestro con un registro de git muy limpio, reduciendo el desorden de múltiples fusiones de nuestra rama compartida para que nuestra rama "se ponga al día" con el último maestro (rama compartida)

El cuarto paso es REALMENTE importante y una de las principales razones por las que comencé a abogar por el uso de rebase. force-with-leasecomprueba el control remoto para ver si se han agregado nuevas confirmaciones. Si git pushse demostró que es destructivo, ¡no presionará!

Espero que esto le dé a alguien más confianza para usar rebase.