¿Es tan esencial el git "Regla de oro de la reformulación"?

Recientemente tuve una discusión con personas absolutamente opuestas a una estrategia de rebase de ramas de características en GIT. Parece ser un patrón aceptado para usar rebase solo para sucursales locales y privadas, pero nunca lo use cuando haya varias personas trabajando en una misma característica y rama, según esta llamada "Regla de Oro de Rebasar" (como se explica aquí: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

Me sorprende que haya un consenso sobre esto. Trabajé 3 años con una estrategia de rebase completa, con unos 20 desarrolladores trabajando juntos y adivina qué, funcionó.

El proceso es básicamente:

• Usted crea su rama de características, llamémosla "myfeature" y la empuja a origin / myfeature
• Otras personas pueden echarle un vistazo y trabajar en ello
• A veces puede volver a crear una base desde master: desde "myfeature", git rebase origin / master ; y luego, sí, tienes que forzarlo.
• ¿Qué sucede cuando otras personas quieren forzar sus compromisos? Simplemente lo reescriben: git rebase origin / myfeature . Entonces ahora están en avance rápido y pueden empujarlo sin forzar.

El único principio a respetar es que la rama característica es propiedad de alguien . El propietario es el único que puede forzar la fuerza.

Entonces, admito: tan pronto como hay una fuerza de empuje, existe el riesgo de cometer errores. Es verdad. Pero también hay muchas maneras de recuperarse de los errores, y realmente, en 3 años de desarrollo, no vi muchos errores de fuerza, y cuando sucedió, siempre encontramos una manera de recuperarnos adecuadamente.

Entonces, ¿por qué esta "Regla de Oro de Rebase" está siendo tan ampliamente aceptada? ¿Hay algo más que me perdí con eso? Entiendo que requiere un mínimo de organización (cada estrategia requiere alguna organización), pero funciona.

El problema con el empuje forzado no se trata de la rama de características y el maestro, sino de empujar su maestro al maestro de otra persona: esa sincronización va a sobrescribir su maestro con sus cambios, ignorando lo que sea que esté en su punta.

Teniendo en cuenta este peligro, hay una razón por la que no debería usarlo en absoluto a menos que las cosas se hayan estropeado y absolutamente, debe usarlo para realizar reparaciones. Un sistema SCM nunca debería necesitar ser forzado de esta manera, si lo hace porque algo salió terriblemente mal (y mi primer enfoque en tales casos sería restaurar las copias de seguridad y repetir las operaciones para mantener el historial intacto).

Entonces, tal vez la pregunta es ¿por qué estás haciendo rebase? ¿Para un historial "limpio" cuando las características vuelven a ser maestras? Si es así, está desechando toda la buena historia sobre la ramificación por razones puramente de estilo. La fusión de avance rápido de la OMI tampoco es una buena práctica, debe mantener todo el historial para que pueda ver lo que realmente hizo, no una versión desinfectada después.

Rebase no es esencial, ya que usted dice que es principalmente cosmético. A veces es mucho más simple que una fusión. Por lo tanto, puede tener un valor "real", pero solo "a veces"

El uso inadecuado de rebase puede ser costoso. Es improbable que pierda datos si sabe lo suficiente como para no entrar en pánico y buscar procedimientos de recuperación, pero "oye, nadie presione por un tiempo, tengo que arreglarlo ..." no es genial. Tampoco es que alguien pierda tiempo en la recuperación de la investigación y las pruebas cuando podrían haber estado agregando características o eliminando errores (o en casa con la familia).

Con esa compensación, los resultados de "muy pocas personas hacen un rebase y un empuje forzado" no es muy sorprendente.

Algunos flujos de trabajo pueden reducir el riesgo, por ejemplo, reducirlo a "cero siempre que recuerde qué ramas puede forzar y cuáles no". En realidad, podrían ser lo suficientemente seguros como para justificar el riesgo, pero la gente frecuentemente toma decisiones basadas en un folclore más amplio. Por otra parte, en realidad, los beneficios son bastante pequeños, entonces, ¿qué tan pequeño realmente debe ser el riesgo?

Para agregar una voz diferente:

Sí, si trabaja como lo describe, no hay problema con el uso rebasey el empuje forzado. El punto crítico es: tiene un acuerdo en su equipo.

Las advertencias rebasey amigos son para el caso donde no hay un acuerdo especial. Normalmente, git lo protege automáticamente, por ejemplo, al no permitir un empuje que no avance rápidamente. El uso rebasey el empuje forzado anulan esa seguridad. Eso está bien si tienes algo más en su lugar.

En mi equipo, a veces también cambiamos las ramas de características si la historia se ha vuelto desordenada. O eliminamos la rama anterior y hacemos una nueva con un nombre nuevo, o simplemente coordinamos de manera informal (lo cual es posible porque somos un equipo pequeño y nadie más trabaja en nuestro repositorio).

Tenga en cuenta que el proyecto git en sí mismo también hace algo similar: tienen una rama de integración que se recrea regularmente, llamada "pu" ("actualizaciones propuestas"). Está documentado que esta rama se recrea regularmente y que no debe basar nuevos trabajos en ella.

Entonces, admito: tan pronto como hay una fuerza de empuje, existe el riesgo de cometer errores. Es verdad. Pero también hay muchas maneras de recuperarse de los errores, y realmente, en 3 años de desarrollo, no vi muchos errores de fuerza, y cuando sucedió, siempre encontramos una manera de recuperarnos adecuadamente.

La razón por la cual los usuarios de Git tienden a evitar el historial de mutación compartida es porque no hay una evitación o reparación automática de estos problemas. Tienes que saber lo que estás haciendo, y tienes que arreglar todo manualmente si te equivocas. Permitir que exactamente una persona haga fuerza de empuje no es intuitivo y contrario al diseño distribuido de Git. ¿Qué pasa si esa persona se va de vacaciones? ¿Alguien más posee temporalmente la sucursal? ¿Cómo sabes que no caminarán por todo lo que el dueño original estaba haciendo? Y en el mundo del código abierto, ¿qué sucede si el propietario de la sucursal se aleja gradualmente de la comunidad, sin irse oficialmente? Podría perder mucho tiempo esperando entregar la propiedad de la sucursal a otra persona.

Pero el problema real es este: si cometes un error y no te das cuenta de inmediato, los viejos compromisos eventualmente desaparecerán después de que haya transcurrido el tiempo suficiente. En ese momento, el problema puede ser irrecuperable (o al menos, potencialmente muy difícil de recuperar, dependiendo de cómo se vea su historia de respaldo: ¿hace copias de seguridad de las copias antiguas de su repositorio Git, es decir, no solo clones?).

Compare esto con el trabajo de evolución Changeset de Mercurial (que, debo señalar, aún no está terminado o es estable). Todos pueden realizar los cambios en el historial que deseen, siempre que los conjuntos de cambios no estén marcados como públicos. Estas enmiendas y rebases se pueden empujar y tirar con total impunidad, sin necesidad de un propietario de sucursal. No se eliminan datos nunca; todo el repositorio local es solo para agregar. Los conjuntos de cambios que ya no son necesarios se marcan como obsoletos, pero se mantienen indefinidamente. Finalmente, cuando arruinas tu historial (que se trata como una parte normal de tu flujo de trabajo diario), hay un comando ingenioso para limpiarlo automáticamente. Este es el tipo de UX que la gente espera antes de modificar la historia compartida.