git - practices - Squash y fusionar maestro en la misma rama

git tag push (4)

¿Hay una manera de aplastar y fusionar maestro en la misma rama? ¿Tomar efectivamente todos los compromisos pendientes y ponerlos en 1 compromiso?

Mi idea original es un script que toma my-branch y hace un git checkout master && git pull && git checkout my-branch-squashed y luego git merge --squash my-branch (lidiar con cualquier conflicto de fusión) y luego finalmente eliminar my-branch y renombra my-branch-squash a my-branch

Esto parece muy general y posiblemente malo, así que estoy tratando de ver si hay alguna otra manera. La intención que estoy tratando de resolver es que cuando coloco ramas en github y éstas se "aplastan y fusionan" en master, la rama que existe en la máquina local no coincide con la rama que se fusionó en master, por lo que al usar git branch --merged ${1-master} | grep -v " ${1-master}$" | xargs -r git branch -d; git branch --merged ${1-master} | grep -v " ${1-master}$" | xargs -r git branch -d; no elimina correctamente las ramas que ya se han fusionado en el maestro. Lo que quiero es una forma de eliminar automáticamente las ramas antiguas que se han fusionado en el maestro

Dejando a un lado los problemas con el flujo de trabajo de fusión y squash, que ya se han discutido a fondo en muchos lugares, a la luz de los flujos de trabajo que a menudo están fuera de su control.

Hay un método que puede usar y, aunque no es 100% efectivo, en mi experiencia tiene un historial bastante bueno y siempre falla.

Sin un antecedente en el que confiar, necesita una forma de determinar si dos instantáneas son idénticas. Puedes usar el hash de los árboles de los compromisos con este comando:

git show --format="%T" <committish>

Para verificar si se puede eliminar una rama, primero combine el maestro en su rama. Si hay un conflicto en esta combinación, o hubo un conflicto en el squash original, no podrá usar este método (esta es la parte menos efectiva del 100%).

Gracias a la naturaleza de git, no importa en qué orden se apliquen un conjunto de parches si no se producen conflictos. Por lo tanto, si el resultado de esta combinación debe ser idéntico al jefe de maestro si su rama se ha fusionado. Esto se puede confirmar comparando los hashes de árbol de las dos cabezas de rama que puede averiguar si existe algún código no fusionado en su rama.

Esto podría reducirse a un comando para un solo uso que puede ser fácilmente alias como:

if [ $(git show --format="%T" origin/master) = $(git show --format="%T" HEAD) ]; then echo Merged; else echo Unmerged; fi

O integrado en un script de shell que recorrerá todas las sucursales locales, las combinará, las probará y eliminará las que se han fusionado.

Todo lo que se dice, el uso de rebase interactiva para aplanar su sucursal y lograr que el mantenedor use una estrategia de combinación de avance rápido solo en las solicitudes de extracción hará que todo esto sea innecesario.

Puede hacer eso usando git rebase , y arreglar las confirmaciones que desea combinar:

$ git rebase -i HEAD~5 pick c2e2c87 commit 1 f 689d474 commit 2 f aa9d9b4 commit 3 f 888a009 commit 4 f d396e75 commit 5 # Rebase 2f7f53e..d396e75 onto 2f7f53e (5 commands) # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit''s log message # x, exec = run command (the rest of the line) using shell # d, drop = remove commit # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out

Puede usar git rebase -i --root para rebautizar desde la primera confirmación.

Puede reiniciar por software el último compromiso que desee y volver a confirmar.

Si todo lo que realmente desea es aplastar su historial de desarrollo local antes de enviar una solicitud de extracción, la forma más sencilla es desarrollarlo en una rama de función local que sea diferente de cualquier rama de subida que desee afectar.

Entonces, el procedimiento para aplastarlo sobre el maestro es

git checkout master git merge --squash feature

(reemplazar master con integration o lo que sea).

rebase -i para un control preciso, pero para este caso simple podemos usar el conocimiento de git de su historial para descubrir automáticamente el último ancestro común.