Wie pragmatisch mit Bash-Skript überprüfen, wenn eine Verzweigung in Git muss rebased werden?

Ich arbeite an einem Bash-Skript für mein Team, um eine regelmäßige Neuausrichtung von Arbeitsbereichen zu erzwingen. Das Problem, auf das ich momentan stoße, ist, wie man feststellen kann, ob eine Verzweigung hinter dem Master steht und/oder ob sie rebasiert werden muss, anstatt blind den Zweig zu rebasen.Wie pragmatisch mit Bash-Skript überprüfen, wenn eine Verzweigung in Git muss rebased werden?

Hier ist eine vereinfachte Version von dem, was ich bisher:

#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

Irgendwelche Ideen sehr geschätzt werden würde. Vielen Dank!

Quelle

2015-05-11 Jim Fell

Ich denke, das ist nicht nötig. 'git rebase' sollte das überprüfen und sich in ein no-op verwandeln (" Current branch ist auf dem neuesten Stand. "), wenn die Zweigstelle den Kopf des Masters in seinem Commit-Protokoll hat. – PSkocik

@PSkocik Mein Grund, dies zu tun, ist eine andere als "git rebase" Fähigkeit zur Selbstüberprüfung. Es gibt andere Aktionen, die mein Skript ausführen soll, abhängig davon, ob eine Rebase benötigt wurde oder nicht. –

Um festzustellen, ob Sie Ihren Zweig neu erstellen müssen, müssen Sie herausfinden, was das letzte Festschreiben ist und was das letzte Festschreiben war, das Ihre zwei Zweige teilen.

Um die letzte commit auf dem Zweig zu finden:

git show-ref --heads -s <branch name>

Dann wird die letzte zu finden verpflichten, dass Ihre Filialen gemeinsam haben:

git merge-base <branch 1> <branch 2>

Alles was Sie jetzt tun müssen, ist herauszufinden, ob Diese beiden Commits sind die gleichen Commit. Wenn dies der Fall ist, müssen Sie nicht umbuchen. Wenn dies nicht der Fall ist, ist eine Rebase erforderlich.

Beispiel:

hash1=$(git show-ref --heads -s master) 
hash2=$(git merge-base master foo/bar) 
[ "${hash1}" = "${hash2}" ] && echo "OK" || echo "Rebase is required"

Obwohl wie im Kommentar angegeben, wenn Sie einen Zweig re versuchen, die bereits auf dem neuesten Stand ist. Git wird elegant mit der Situation umgehen und beenden.

Quelle

2015-05-11 20:39:02 Schleis

Dies scheint zu funktionieren, wenn der lokale Master auf dem gleichen Commit-Level wie der letzte Commit des Arbeitszweiges ist. Es wird jedoch nicht behandelt, wenn der Arbeitszweig bereits auf dem Master basiert, sondern mehrere Commits vor dem Master. Irgendwelche Ideen? –

In welchem Zweig machst du 'show-ref'? Es sollte Meister sein. Grundsätzlich sind die beiden Befehle zu überprüfen und zu sehen, ob das letzte Commit auf Master die Merge-Base für den Arbeitszweig ist. Die Commits, die in der Arbeitsbranche sind, sollten überhaupt keine Rolle spielen. – Schleis

Danke! Es funktioniert jetzt viel besser. :) –

Wie pragmatisch mit Bash-Skript überprüfen, wenn eine Verzweigung in Git muss rebased werden?

Antwort

Verwandte Themen