Jim cayó
Estoy trabajando en un script bash para que mi equipo haga cumplir el reajuste regular de las ramas en funcionamiento. El problema al que me enfrento en este momento es cómo determinar si una rama está detrás de la maestra y/o si necesita ser reorganizada, en lugar de intentar reorganizar ciegamente la rama.
Aquí hay una versión simplificada de lo que tengo hasta ahora:
#Process each repo in the working directory.
for repo_dir in $(ls -1); do
# if working branch is clean ...
# BEGIN update of local master
git checkout master
git fetch origin
git merge remotes/origin/master
# END update of local master
for sync_branch in $(git branch | cut -c 3-); do
if [ "$sync_branch" != "master" ]; then
# BEGIN rebase working branch
git checkout $sync_branch
git rebase master
# Do NOT push working branch to remote.
# END rebase working branch
fi
done
fi
done
Cualquier idea será altamente apreciada. ¡Gracias!
Schleis
Para saber si necesita reorganizar su sucursal, debe averiguar cuál es la última confirmación y cuál fue la última confirmación que comparten sus dos sucursales.
Para encontrar la última confirmación en la rama:
git show-ref --heads -s <branch name>
Luego, para encontrar el último compromiso que sus sucursales tienen en común:
git merge-base <branch 1> <branch 2>
Ahora todo lo que necesita hacer es averiguar si estos dos compromisos son el mismo compromiso. Si lo son, entonces no es necesario volver a establecer la base. Si no lo son, se requiere una rebase.
Ejemplo:
hash1=$(git show-ref --heads -s master)
hash2=$(git merge-base master foo/bar)
[ "${hash1}" = "${hash2}" ] && echo "OK" || echo "Rebase is required"
Aunque como se indica en el comentario, si intenta cambiar la base de una rama que ya está actualizada. Git manejará la situación con gracia y saldrá.
-
Esto parece funcionar cuando el maestro local está en el mismo nivel de confirmación que la última confirmación de la rama de trabajo. Sin embargo, no maneja cuando la rama de trabajo ya puede estar basada en el maestro, pero está varias confirmaciones por delante del maestro. ¿Algunas ideas?
– Jim Cayó
12 mayo 2015 a las 18:49
-
que sucursal haces
show-ref
¿en? Debe ser maestro. Básicamente, los dos comandos son para verificar y ver si la última confirmación en el maestro es la base de fusión para la rama de trabajo. Las confirmaciones que están en la rama de trabajo no deberían importar en absoluto.– Schleis
12 mayo 2015 a las 19:06
Creo que no hay necesidad de eso. está actualizada”) si la rama tiene el jefe del maestro en su registro de confirmación.
git rebase
debería verificar eso y convertirse en un no-op (“La rama actual– PSkocik
11 mayo 2015 a las 20:38
@PSkocik Mi razón para querer hacer esto es otra que
git rebase
La capacidad de autocontrol. Hay otras acciones que quiero que realice mi secuencia de comandos dependiendo de si se necesita o no una reorganización.– Jim Cayó
11 mayo 2015 a las 21:04
Creo que esto tiene sentido. Mi caso de uso es que no podemos hacer
git rebase
si hay cambios no almacenados/no preparados, por lo que es bueno verificar explícitamente antes de ejecutar el comando para scripts/Makefiles.– Seth Falcó
13 abr a las 10:50