git rebase en funciones de larga duración (remoto) ramas

Question

Antecedentes: Utilizamos github para nuestro proyecto y trabajo en mi propia bifurcación de nuestro repositorio principal. Usamos rebase en lugar de fusionar para evitar grandes confusiones de fusión.

Escenario: La manera en que yo quiero trabajar es la siguiente:

1. Al implementar una nueva característica, crear una rama local de la maestra de mi tenedor y poner en mis cambios allí. I y otros miembros del grupo hacen muchas confirmaciones pequeñas, por lo que casi siempre habrá varias confirmaciones que afecten al mismo archivo en la rama.
2. Empuje la rama local a mi tenedor para que tenga una copia remota de lo que estoy trabajando (no quiero perder todos mis cambios si mi computadora portátil se muere o se pierde. Intento hacerlo al final de cada día).
3. Si se necesita mucho tiempo para terminar la función, de vez en cuando rebase el maestro de mi tenedor para asegurarse de que no ha habido cambios que podrían romper mi función. Esto generalmente funciona bien.
4. mantener la copia remota de la rama actualizada, empujo mi sucursal local para que después del rebase.

Problema: Paso 4 es donde me dan problemas. Casi siempre tengo que lidiar con commits no rápidos y uso git push --force.

He mirado en

Git: how to maintain permanent parallel branches

How to maintain (mostly) parallel branches with only a few difference

y no han encontrado una manera de hacer mi trabajo flujo de trabajo. Hacer una búsqueda en google en los flujos de trabajo de git, en su mayoría, arroja resultados que dan por hecho que todos trabajas en ramas locales y no guardas una copia remota en github (por ejemplo, http://nvie.com/posts/a-successful-git-branching-model/).

Soy relativamente nuevo en Git, así que me gustaría saber si me falta algo aquí. Me gustaría poder hacer el paso 4 sin una fuerza. Un flujo de trabajo alternativo que todavía me permita usar rebase en lugar de combinar y mantener una copia remota de mi sucursal local también sería muy útil.

Answer 1

git push --force es una realidad cuando se trata de rebase y ramas remotas, porque git push no hará un avance sin avance rápido sin él. La mayoría de las cosas en git suponen que la historia solo se agrega, nunca se edita, y la rebase rompe esa suposición, por lo que hay que hacer algunas cosas bastante torpes para que funcione.

Solíamos utilizar un flujo de trabajo de rebase muy similar al que usted describe, pero finalmente volvimos a un flujo de trabajo de fusión después de un tiempo. Rebasing le proporciona un historial agradable, bonito y lineal, pero tiene muchos inconvenientes, como requerir --force, perder la capacidad de ver el estado de una rama antes de fusionarse en el maestro, etc.

Como Amber menciona, rebase hace que sea muy difícil trabajar con otras personas en la misma rama - antes de git push --force ing, tiene que ver el estado de la rama remota para ver si alguien más lo presionó primero, y pull --rebase que en, luego git push --force. Incluso esto tiene una condición de carrera: si alguien presiona justo delante de usted push --force, sus cambios serán sobrescritos por el suyo.

Answer 2

Si tiene rebase ing, siempre tendrá que --force al presionar, porque rebase reescribe el historial. Así es como funciona. El historial reescrito no avanzará por encima de ese mismo historial por definición.

La alternativa es merge en lugar de rebase ing. Podría usar su mismo flujo de trabajo exacto, excepto con merge en lugar de rebase, y no tendría que forzar push.

Si nadie más está utilizando su control remoto aparte de usted, entonces usar --force no es intrínsecamente malo. Si otras personas son usando la rama remota, probablemente debería utilizar merge de todos modos.