En realidad, existe una tercera posibilidad, y muy probablemente muchas otras, ya que GIT es más una implementación de un marco SCM que una implementación de una metodología SCM. Esta tercera posibilidad se basa en rebase
.
El rebase
subcomando GIT toma una serie de commit (generalmente desde su punto de ramificación hasta la punta de su rama temática topic
) y los reproduce en otro lugar (típicamente en la punta de su rama de integración, por ejemplo master
). El rebase
subcomando produce nuevas confirmaciones, lo que brinda la oportunidad de reorganizar las confirmaciones de una forma que es más fácil de revisar. Esto produce una nueva serie de commit, similar a lo que topic
solía ser pero que aparece arraigado en la parte superior de la rama de integración. topic
GIT todavía llama a esta nueva rama , por lo que se descarta la referencia anterior. Etiqueto informalmente topic-0
el estado original de su sucursal topic-1
y así sucesivamente sus diversas refactorizaciones.
Aquí está mi sugerencia para su topic
sucursal:
(Paso opcional) Reorganiza interactivamente la rama de su tema topic
en su punto de ramificación (vea la --fixup
opción para commit
y las opciones -i
y --autosquash
en rebase
), lo que le brinda la oportunidad de reescribir sus confirmaciones de una manera que sea más fácil de revisar. Esto da como resultado una rama topic-1
.
Reorganiza su rama de tema en la parte superior de su rama de integración, es similar a hacer una fusión, pero "no contamina" el historial con una fusión que no es más que un artefacto de ingeniería de software. Esto da como resultado una rama topic-2
.
Enviar topic-2
a un compañero de equipo que lo revisa en contra de la punta de master
.
Si topic-2
está bien, combínalo con master.
NOTA: Las ramas, donde rama se refiere al árbol de confirmación, serán todas llamadas por GIT, por lo tanto, al final del proceso, solo la rama topic-2
tiene un nombre en GIT.
Pros:
- No hay código obsoleto en revisión.
- No hay revisiones espurias de "fusiones extranjeras" (el fenómeno que describió en 1er).
- Oportunidad de reescribir los compromisos de una manera limpia.
Contras:
- En lugar de una rama
topic-0
, hay tres artefactos ramas topic-0
, topic-1
y topic-2
que se crean en el árbol de confirmación. (Aunque en cualquier momento, solo uno de ellos tiene un nombre en GIT).
En su primer escenario «si alguien fusionó algo entre" 1 ". y "2." »se refiere al tiempo que transcurre entre la creación del punto de ramificación y el momento en que decide fusionarse. En este escenario «si alguien fusionó algo entre" 1 ". y "2." »se refiere al tiempo que transcurre entre el rebase y la fusión, que generalmente es muy corto. Por lo tanto, en el escenario que proporciono, puede "bloquear" la master
rama durante el tiempo de la fusión sin perturbar significativamente su flujo de trabajo, mientras que no es práctico en el primer escenario.
Si está realizando revisiones sistemáticas de código, probablemente sea una buena idea reorganizar las confirmaciones de manera adecuada (paso opcional).
La gestión de los artefactos de rama intermedios solo presenta una dificultad si los comparte entre repositorios.