Cuando estoy trabajando en una rama de características, tiendo a querer limpiar los commits en la rama usando un rebase interactivo antes de que mi trabajo sea revisado e integrado en la rama principal.

Durante el desarrollo de la función, quiero llevar mi trabajo intermedio al repositorio remoto como una medida de respaldo. Es decir, cuando mi disco duro falla, no quiero que se pierda toda la rama de funciones.

Sin embargo, esto lleva al hecho de que a menudo tengo que hacerle una consulta git push --forceal repositorio remoto después de un rebase, una acción que generalmente está mal vista. O como dice la página de github vinculada:

Debido a que cambiar su historial de confirmación puede dificultar las cosas para todos los que usan el repositorio, se considera una mala práctica cambiar las confirmaciones cuando ya se ha presionado a un repositorio.

¿Existe una política (generalmente aceptada) que resuelva este conflicto?

¿Por qué esto no es un duplicado de Es tan esencial la git "Regla de Oro de Rebasar"?

Mi pregunta aquí pide una política para resolver el conflicto entre querer hacer una copia de seguridad de su trabajo en el repositorio remoto y cambiar su trabajo , mientras que la otra pregunta trata de negar que haya un conflicto y pregunta por qué algunas personas piensan que el conflicto existe. y por lo tanto pregunta por qué "es esencial" no impulsar rebases de fuerza?

La pregunta clave que debe hacerse:

• ¿Mantiene su rama remota después de volver a fusionarse con el maestro?

Si elimina su rama de funciones remotas después de fusionarse con master, ya está perdiendo el historial. Suponiendo que aplaste / rebase la rama antes de hacer su fusión / PR, perderá este historial. Todo lo que está haciendo su fuerza en este caso es permitirle usar github como respaldo.

La situación en la que desea mantener el historial y no forzar el empuje es si su rama remota persiste después de fusionarse y no solo existe por un período de tiempo temporal.

¿Supongo que me preguntas si me quedaría con la rama sin base? No, AFAIC. Aún así, forzarlo podría, en teoría, provocar la pérdida de confirmaciones de otros usuarios que empujaron a la misma rama

Parece que tienes varias personas empujando a esa rama simultáneamente. Esto significa que te importa el historial de la sucursal.

Lo que podría hacer en su lugar para su trabajo intermedio es crear una bifurcación de esa rama. Puede presionar para esto y luego volver a basar todas sus confirmaciones en una sola confirmación antes de fusionarlas, por lo que cuando las combina en su rama característica, solo tiene 1 confirmación (con el historial modificado de toda su rama).

Aquí enumero algunas posibilidades que se me pasan por la cabeza.

Rebasar siempre en una nueva sucursal

Cuando tenga una rama desordenada some-feature, vuelva a crear una nueva rama. P.ej

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

Luego han some-feature-rebaserevisado e integrado.

Problema: un gran inconveniente aquí es que, estrictamente hablando, necesita una nueva rama para cada rebase. (Podría tener múltiples rebases si realiza cambios después de una revisión de código, por ejemplo)

Utilizar git push --force-with-lease

Acabo de enterarme de la git push --force-with-leasealternativa agit push --force , que

se niega a actualizar una rama a menos que sea el estado que esperamos; es decir, nadie ha actualizado la rama aguas arriba.

Problema : Esto parece mejorar directamente en la situación en la que usamos solo --force, pero todavía tiene algunas advertencias, sobre todo cuando hago un en git fetchlugar de un git pull, que actualiza nuestras ramas locales aguas arriba, engañando --force-with-leasepara pensar que no se realizaron cambios no fusionados en el control remoto rama.