Blog

Was tun, wenn ihr in den falschen Git-Branch committet habt – Teil 2

SEP 15, 2020

Das Ende der Welt. Nur ein Scherz! Dieser Fehler ist keine Seltenheit und kann praktisch jedem passieren – Experten wie Einsteigern.

Eficode is the leading DevOps company in Europe, driving and building the future of software development across 10 countries, with 500+ experts in DevOps and sustainable software development. Our Eficode ROOT managed DevOps platform provides centralized access control and real-time visibility of project status, quality, and performance that integrates with 50+ of your preferred tools, including the Atlassian Stack and open-source systems like Jenkins and Kubernetes.

Was es bedeutet, in den falschen Git-Branch zu committen

Angenommen, ihr arbeitet in eurem Git-Repository mit zwei aktiven Branches und committet eines Tages versehentlich ein Update in den falschen Branch, das ihr anschließend auf euren Git-Server pusht (zum Beispiel Bitbucket). Oh je!

Es ist wichtig zu wissen, dass Branch-Berechtigungen auf eurem Git-Server einen guten Schutz vor diesem Fehler bieten. Damit könnt ihr direkte Pushes auf Mainline-Branches blockieren und stattdessen die Nutzung von Feature-Branches und Pull Requests erzwingen.

Nehmen wir an, ihr habt mehrere Commits im falschen Branch vorgenommen. Was nun?

Keine Panik!

Wenn ihr feststellt, dass das passiert ist, solltet ihr innehalten und prüfen, welche der Commits im falschen Branch bereits mit anderen geteilt wurden, also auf euren Git-Server gepusht wurden.

Die goldene Regel lautet: Schreibt niemals die Historie eines Branches um, den ihr bereits auf einen Git-Server gepusht und mit anderen geteilt habt.

Angenommen, auf dem Server gibt es zwei Branches:

  • MG-200-correct-branch

  • MG-201-wrong-branch

Ihr dachtet, ihr arbeitet an MG-200-correct-branch, tatsächlich habt ihr aber an MG-201-wrong-branch gearbeitet.

Zuerst müsst ihr einen Befehl ausführen, mit dem ihr sehen könnt, welche Commits auf den Server gepusht wurden und welche nicht:

git log --decorate --oneline

Hier ist eine Beispielausgabe:

afada1d (HEAD -> MG-201-wrong-branch) change on wrong branch (local)

630c250 (origin/MG-201-wrong-branch) change on wrong branch (pushed)

9a208bc (origin/develop, origin/MG-200-correct-branch, origin/HEAD, develop, MG-200-correct-branch) Task-123: activity

Das Argument „--oneline“ hält die Ausgabe kurz (eine Zeile pro Commit), und das Argument „--decorate“ zeigt, auf welche Commits eure Referenzen verweisen.

Die roten Referenzen, die mit origin/ beginnen, sind Remote-Branch-Referenzen. Eine Remote-Referenz zeigt euch, auf welche Commits die Server-Branches beim letzten Kontakt mit dem Server verwiesen haben, also als ihr Änderungen per Fetch oder Pull abgerufen habt.

Die grünen Referenzen sind eure lokalen Branches. Wenn es eine Weile her ist, seit ihr eure Änderungen geteilt, also gepusht habt, stimmen diese Referenzen nicht mit den Remote-Branch-Referenzen überein.

Die obige Ausgabe zeigt:

  1. Der neueste Commit, den ihr geteilt, also auf den Server gepusht habt und der MG-201-wrong-branch zugeordnet ist, lautet 630c250. Das wissen wir, weil neben diesem Commit die Remote-Branch-Referenz „origin/MG-201-wrong-branch“ steht. Ihr befindet euch im lokalen Branch MG-201-wrong-branch und habt in diesem Branch einen Commit lokal erstellt (afada1d).

  2. Der neueste Commit, den ihr geteilt, also auf den Server gepusht habt und der MG-201-wrong-branch zugeordnet ist, lautet 630c250. Das wissen wir, weil neben diesem Commit die Remote-Branch-Referenz „origin/MG-201-wrong-branch“ steht.

  3. Ihr befindet euch im lokalen Branch MG-201-wrong-branch und habt in diesem Branch einen Commit lokal erstellt (afada1d).

Bringen wir zunächst alle Änderungen dorthin, wo sie eigentlich hingehören, also in den Branch MG-200-correct-branch.

Dazu lässt du MG-200-correct-branch auf den Commit zeigen, auf den MG-201-wrong-branch derzeit zeigt:

git checkout MG-200-correct-branch

git reset --hard MG-201-wrong-branch

Danach sieht die Ausgabe von „git log --decorate --oneline“ so aus:

afada1d (HEAD -> MG-200-correct-branch, MG-201-wrong-branch) change on wrong branch (local)

630c250 (origin/MG-201-wrong-branch) change on wrong branch (pushed)

9a208bc (origin/develop, origin/MG-200-correct-branch, origin/HEAD, develop) Task-123: activity

Du kannst MG-200-correct-branch jetzt teilen, da er die richtigen Commits enthält:

git push origin MG-200-correct-branch

… und die Log-Ausgabe sieht jetzt so aus:

afada1d (HEAD -> MG-200-correct-branch, origin/MG-200-correct-branch, MG-201-wrong-branch) change on wrong branch (local)

630c250 (origin/MG-201-wrong-branch) change on wrong branch (pushed)

9a208bc (origin/develop, origin/HEAD, develop) Task-123: activity

Mit MG-200-correct-branch ist jetzt also alles in Ordnung. MG-201-wrong-branch enthält jedoch weiterhin die falschen Commits. Bevor du feiern kannst, bleibt also noch etwas zu tun.

Die gute Nachricht: Du hast deinen Commit afada1d noch nicht zu MG-201-wrong-branch gepusht (geteilt). Du kannst das also erneut mit reset korrigieren – wahrscheinlich einer deiner wichtigsten Git-Befehle, wenn du Probleme beheben musst:

git checkout MG-201-wrong-branch

git reset --hard HEAD~1

Damit machst du zumindest die lokalen Änderungen an MG-201-wrong-branch rückgängig. Das Git-Log sieht jetzt so aus:

630c250 (HEAD -> MG-201-wrong-branch, origin/MG-201-wrong-branch) change on wrong branch (pushed)

9a208bc (origin/develop, origin/HEAD, develop) Task-123: activity

Beachte, dass du die Referenzen für MG-200-correct-branch nicht mehr sehen kannst: Das liegt daran, dass sie von deiner aktuellen Position im Git-Commit-Verlauf nicht mehr erreichbar sind.

Das letzte Problem ist allerdings etwas kniffliger. Dein Commit 630c250 wurde auf den Server gepusht und mit anderen geteilt. Wie bereits erwähnt, ist es ein absolutes No-Go, den Verlauf eines Branches umzuschreiben, der bereits auf einen Git-Server gepusht und mit anderen geteilt wurde.

Daher erstellst du am besten einen weiteren Commit, der die Änderungen, die du versehentlich committet und gepusht hast, effektiv rückgängig macht.

In der Regel ist die beste Lösung also, eine weitere Änderung vorzunehmen, die die gepushten Codeänderungen rückgängig macht.

Zum Glück bietet Git für eine solche Situation den Befehl „git revert“:

$ git revert HEAD

Nachdem ihr die Änderung gepusht habt (git push origin MG-201-wrong-branch), sieht euer Git-Log wie folgt aus:

88431f1 (HEAD -> MG-201-wrong-branch, origin/MG-201-wrong-branch) Revert "change on wrong branch (pushed)"

630c250 change on wrong branch (pushed)

9a208bc (origin/develop, origin/HEAD, develop) Task-123: activity

Um zu überprüfen, dass sich eure Dateiänderungen nicht mehr auf MG-201-wrong-branch befinden, verwendet git diff:

git diff 88431f1 9a208bc

git diff gibt keine Ausgabe zurück, wenn die Commits denselben Repository-Inhalt darstellen.

Zum Schluss könnt ihr zum richtigen Branch wechseln und mit eurem Tag weitermachen! :-)

git checkout MG-200-correct-branch

Erledigt!

Wir hoffen, dass dieser Blog für euch hilfreich war. Wenn ihr weitere Unterstützung benötigt, sprecht gerne mit einem unserer Experten.

Clearvision (jetzt Teil von Eficode) bietet Schulungen für Unternehmen jeder Größe zu einer Vielzahl von Softwareanwendungen und -systemen, einschließlich Git, damit ihr eure Ziele erreicht.

  • DevOps
  • Atlassian

Subscribe to our newsletter