Git ist ein verteiltes Versionskontrollsystem, bei dem die meisten Operationen reversibel sind — aber den richtigen Umkehrbefehl zu finden, erfordert ein Verständnis von Gits internem Modell aus Arbeitsverzeichnis, Staging-Bereich (Index) und Commit-Historie. Häufige Fehler wie der Commit auf dem falschen Branch, das Pushen sensibler Daten oder ein fehlerhafter Merge erfordern jeweils unterschiedliche Kombinationen von git reset, git revert, git rebase und git filter-branch.
Welche Git-Fehler passieren am häufigsten?
Die häufigsten Git-Notfälle lassen sich in einige Kategorien einteilen: Commit auf dem falschen Branch, einen kürzlichen Commit rückgängig machen, versehentlich sensible Daten gepusht und einen Merge rückgängig machen. Jedes Szenario hat eine andere Lösung, je nachdem, ob Sie bereits auf den Remote-Server gepusht haben. Der obige Entscheidungsbaum führt Sie durch diese Verzweigungspfade, um die sicherste Lösung zu finden. Bei nicht gepushten Commits ist git reset meist die beste Wahl, bei bereits gepushten Änderungen git revert.
Was ist der Unterschied zwischen git reset und git revert?
git reset schreibt die Historie um, indem der Branch-Zeiger zurückbewegt wird. Es gibt drei Varianten: --soft (behält Änderungen im Staging-Bereich), --mixed (behält Änderungen als nicht gestaged, Standard) und --hard (verwirft alle Änderungen). Reset ist sicher für lokale, nicht gepushte Commits — aber gefährlich für gemeinsame Historie, da es Mitarbeiter zwingt, divergierte Branches abzugleichen.
git revert erstellt einen neuen Commit, der die Änderungen eines bestimmten Commits rückgängig macht. Es bewahrt die vollständige Historie und ist damit sicher für gepushte, gemeinsame Branches. Faustregel: Verwenden Sie reset für nicht gepushte Fehler, revert für gepushte. Arbeiten Sie mit regulären Ausdrücken in Ihren Git-Hooks? Probieren Sie unseren Regex Tester.