¿Es la "regla de oro del cambio de base" de git tan esencial?

Pregunta:

Recientemente tuve una discusión con personas que se oponían absolutamente a una estrategia de rebase de las ramas de funciones en GIT. Parece ser un patrón aceptado usar rebase solo para sucursales privadas locales, pero nunca lo use cuando hay varias personas trabajando en una misma función y sucursal, según esta denominada "Regla de oro de cambio de base" (como se explica aquí: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

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

El proceso es básicamente:

  • Usted crea su rama de características, llamémosla "myfeature" y la enviamos a origin / myfeature
  • Otras personas pueden comprobarlo y trabajar en él.
  • A veces puede volver a basarlo desde master: desde "myfeature", git rebase origin / master ; y luego, sí, tienes que empujarlo-forzarlo.
  • ¿Qué sucede cuando otras personas quieren impulsar sus compromisos? Simplemente lo modifican: git rebase origin / myfeature . Así que ahora están en avance rápido y pueden empujarlo sin forzar.

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

Entonces, lo admito: tan pronto como hay una fuerza de empuje, existe el riesgo de cometer errores. Eso es cierto. Pero también hay muchas formas de recuperarse de los errores, y realmente, en 3 años de desarrollo, no vi muchos errores de empuje forzado, y cuando sucedió, siempre encontramos una manera de recuperarnos correctamente.

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 (toda estrategia requiere algo de organización), pero funciona.

Respuesta:

El problema con el empuje forzado no se trata de su rama de características y maestro, sino de empujar a 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 consejo.

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 sea absolutamente necesario que lo use para realizar reparaciones. Un sistema SCM nunca debería necesitar ser forzado de esta manera, si lo hace es porque algo salió terriblemente mal (y mi primer enfoque en tales casos sería restaurar copias de seguridad y repetir las operaciones para mantener intacto el historial).

Entonces, tal vez la pregunta sea ¿por qué está rebasando en absoluto? ¿Para tener un historial 'limpio' al volver a dominar las funciones? Si es así, está descartando toda la buena historia relacionada con la ramificación por razones puramente de estilo. En mi humilde opinión, la combinación de avance rápido tampoco es una buena práctica, debería querer mantener todo el historial para poder ver lo que realmente hizo, no una versión desinfectada después.

Leave a Comment

Your email address will not be published. Required fields are marked *

web tasarım