git - example - La fusión de una rama de una rama después de la primera rama se aplasta cuando se combina con el maestro

git merge example

Question

Aquí hay un flujo de trabajo con el que comúnmente trato en el trabajo.

git checkout -b feature_branch
# Do some development
git add .
git commit
git push origin feature_branch

En este punto, la rama de características está pendiente de revisión por parte de mis colegas, pero quiero seguir desarrollando otras funciones que dependen de feature_branch . Entonces, mientras feature_branch está en revisión ...

git checkout feature_branch
git checkout -b dependent_branch
# Do some more development
git add .
git commit

Ahora realizo algunos cambios en respuesta a la revisión del código en feature_branch

git checkout feature_branch
# Do review fixes
git add .
git commit
git checkout dependent_branch
git merge feature_branch

Ahora aquí es donde tenemos problemas. Tenemos una política de squash en master, lo que significa que las ramas de características que se combinan en master deben aplastarse en una única confirmación.

git checkout feature_branch
git log # Look for hash at beginning of branch
git rebase -i first_hash_of_branch # Squash feature_branch into a single commit
git merge master

Todo está bien, excepto con dependent_branch . Cuando trato de volver a vincular la rama dependiente al maestro o intento fusionar el maestro en él, git se confunde con el historial reescrito / aplastado y básicamente marca cada cambio en depedendent_branch como un conflicto. Es un PITA para realizar y, básicamente, volver a hacer o descontextualizar todos los cambios en dependent_branch . ¿Hay alguna solución para esto? A veces, crearé manualmente un parche y lo aplicaré en una nueva rama de master, pero si hay algún conflicto real con eso, es aún peor de arreglar.

git checkout dependent_branch
git diff > ~/Desktop/dependent_branch.diff
git checkout master
git checkout -b new_dependent_branch
patch -p1 < ~/Desktop/dependent_branch.diff
# Pray for a clean apply.

¿Algunas ideas? Sé que esto sucede debido a la historia reescrita durante el squash, pero ese es un requisito que no puedo cambiar. ¿Cuál es la mejor solución / solución? ¿Hay algo de magia que pueda hacer? ¿O hay una forma más rápida de realizar todos los pasos necesarios para crear manualmente el diff?

Answer 1

En este caso particular, parece que "sabes" que solo el trabajo aplastado de la rama en la que originalmente trabajas se ha convertido en maestro.

Así que puedes unirte feliz manteniendo tus cambios cada vez que hay un conflicto. Hay una opción para eso:

git merge -Xours master

Ver https://git-scm.com/docs/git-rebase para más detalles más detalles.

Answer 2

Estoy totalmente en desacuerdo con la política de "mezclar cada función hacia abajo en una única confirmación", pero es su decisión ...

Guardaría las ramas tal como están, y crearía una confirmación purificada solo para su publicación, en una rama especial. Ser capaz de seguir el desarrollo paso a paso es valioso, incluso si la gerencia no cree en él. Marque los lugares de las calabazas por las etiquetas en las ramas "reales", también puede agregar etiquetas entre-squash con mensajes que apuntan a las confirmaciones reales.

Answer 3

Un poco acerca de por qué sucede esto:

Dejaré que O sea ​​"maestro original" y FB sea ​​"nuevo maestro", después de que una rama de características se haya fusionado en:

Diga que feature_branch ve así:

O - A - B - C

dependent_feature tiene algunas confirmaciones adicionales además de eso:

O - A - B - C - D - E - F

Se fusiona la rama de características original en maestro y se aplasta, lo que le da:

O - FB

Ahora, cuando trates de volver a establecer la base de la rama dependiente, git tratará de descubrir el ancestro común entre esas ramas. Si bien originalmente habría sido C , si no hubieras aplastado los commits, git encuentra a O como el ancestro común. Como resultado, git está tratando de reproducir A , B y C que ya están contenidos en FB , y vas a tener un montón de conflictos.

Por este motivo, no puede confiar realmente en un comando de rebase típico, y tiene que ser más explícito al proporcionar el parámetro --onto :

git rebase --onto master HEAD~3 # instruct git to replay only the last
# 3 commits, D E and F, onto master.

Modifique el parámetro HEAD~3 según sea necesario para sus ramas, y no debería tener que lidiar con ninguna resolución de conflicto redundante.

Algunas sintaxis alternativas, si no te gusta especificar rangos y aún no has eliminado la rama de características original:

git rebase --onto master feature_branch dependent_feature
# replay all commits, starting at feature_branch
# exclusive, through dependent_feature inclusive
# onto master