Git-Tricks, die mich gerettet haben

Die meisten Leute verwenden etwa sechs Git-Befehle: clone, pull, add, commit, push und checkout (oder switch). Das reicht für einen normalen Tag. Aber früher oder später geht etwas schief. Ein Kommit auf dem falschen Zweig. Ein Fehler, der irgendwann letzte Woche auftauchte. Ein Schub, der alles zu löschen schien.

Dann werden ein paar weniger verbreitete Befehle zu Lebensrettern. In DevOps, wo Git auch die Infrastruktur ist, ist es noch nützlicher, sie zu kennen.

Umbauen oder fusionieren?

Beide arbeiten in zwei Zweigen zusammen. Sie machen es anders:

• Verschmelzen Erstellt einen Merge-Commit, der die beiden Historien verbindet. Nichts wird umgeschrieben. Die Geschichte zeigt genau, was passiert ist, einschließlich der Verzweigung.
• Wiederherstellung der Basis Wiederholt Ihre Kommits auf dem Zielzweig, als ob Sie von dort aus gestartet wären. Die Geschichte wird eine gerade Linie, aber Ihre Kommitten bekommen neue IDs.

git switch feature
git fetch origin
git rebase origin/main      # put my commits on top of the latest main

Meine Faustregel: Sie können Ihre eigenen lokalen Niederlassungen neu gründen. sie auf dem neuesten Stand zu halten und sauber zu halten; Nicht wieder auf Basis begeht andere Leute bereits haben (gemeinsame Zweige wie Main). Viele Teams vermeiden die Debatte mit Schmelzflut bei Pull-Anfragen: Der gesamte Zweig wird zu einem sauberen Kommit auf Main.

Interaktive Neubewertung Sie können Ihre Kommits vor dem Öffnen einer Pull-Anfrage aufräumen: Squash "Fix typo" Commits, Reorder, Reword Nachrichten.

git rebase -i origin/main

Finden Sie einen Bug mit bisect

"Es hat letzte Woche funktioniert, jetzt nicht mehr. Es gibt 80 Kommits dazwischen". Statt sie einzeln zu überprüfen, lassen Sie Git eine binäre Suche durchführen:

git bisect start
git bisect bad                 # current commit is broken
git bisect good v2.3.0         # this version worked
# Git checks out a commit in the middle. Test it, then:
git bisect good                # or: git bisect bad
# ...repeat about 6-7 times for 80 commits...
git bisect reset

Noch besser, automatisieren Sie es mit einem Test-Skript, das bei einem Ausfall aus dem Nullpunkt kommt:

git bisect run ./scripts/test-login.sh

Git findet den genauen Commit, der das Problem eingeführt hat, normalerweise in Minuten. Es funktioniert auch für Infrastruktur-Repos: "Welche Änderung brach das Helm-Diagramm?"

git bisect verwandelt "es brach irgendwann letzte Woche" in "es brachen in genau diesem Kommit" in etwa sieben Schritten.

Fast alles mit dem Reflog rückgängig machen

Hier ist die beruhigendste Tatsache über Git: Es verliert fast nie wirklich engagierte Arbeit- Ich weiß . Selbst nach einem schlechten Reset, einem verpfuschten Rebase oder einem gelöschten Branch existieren die Commits noch eine Weile. Wiederholung Zeigt überall HEAD hat kürzlich darauf hingewiesen:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~3
# e4f5g6h HEAD@{1}: commit: add retry logic
# ...

git reset --hard e4f5g6h      # go back to before the bad reset
# or recover a deleted branch:
git branch rescued e4f5g6h

Wenn Sie jemals denken: "Ich habe meine Arbeit zerstört", halten Sie an, atmen Sie ein und laufen Sie. git reflog.

Sonstige tägliche Rettungen

Verpflichtet mit dem falschen Zweig:

git switch correct-branch
git cherry-pick <commit>
git switch wrong-branch
git reset --hard HEAD~1       # remove it from the wrong branch (if not pushed)

Beheben Sie den letzten Commit (Nachricht oder vergessen Datei):

git add forgotten-file.yaml
git commit --amend

Undo ein bereits verschobenes Commit, sicher, ohne die Geschichte neu zu schreiben:

git revert <commit>

In GitOps-Setups, git revert ist buchstäblich, wie man einen Einsatz zurückstellt.

Park unvollendete Arbeiten:

git stash push -m "half-done refactor"
git stash list
git stash pop

Wer hat diese Zeile geändert, und warum?

git blame -L 40,60 values.yaml
git log -p -S "replicas: 1" -- deploy/   # find the commit that added or removed a string

Sie müssen sich sicherer drücken ., wenn Sie müssen:

git push --force-with-lease

Im Gegensatz zu --force, wird es abgelehnt, wenn jemand anderes in der Zwischenzeit gedrückt.

Schutz der Zweige

In einem Team ist der sicherste Git derjenige, wo Fehler nicht leicht zum Haupt erreichen können:

• Zweigschutz / Regelwerke: erfordern Pull-Anfragen, Überprüfungen und Prüfungsschecks für Haupt. Blockieren Sie die Schubkraft und Löschen.
• CODEOWNERS: automatisch die richtigen Dateien vom richtigen Team überprüfen lassen. Besonders nützlich für Infrastrukturordner.
• Unterzeichnete Verpflichtungen: mit SSH- oder GPG-Schlüsseln (oder schlüssellos mit Sigstore's gitsign) unterschreiben und Signaturen auf geschützten Zweigen verlangen. Das beweist, dass die Kommitten wirklich von dem kommen, von dem sie behaupten.

# .github/CODEOWNERS
/infrastructure/   @acme/platform-team
/deploy/prod/      @acme/platform-team @acme/sre

Ein paar Konfigurations-Einstellungen, die ich immer benutze

git config --global pull.rebase true          # rebase instead of merge on pull
git config --global rebase.autoStash true     # stash and unstash automatically during rebase
git config --global push.autoSetupRemote true # no more --set-upstream
git config --global rerere.enabled true       # remember conflict resolutions
git config --global init.defaultBranch main

Was sollten Sie also üben?

Versuch ' s mal. git bisect Auf einen echten Fehler und einen Test-Reset durchführen, gefolgt von einer Wiederaufnahme in einem Wegwerf-Repo. Wenn man sich einmal gerettet hat, ist Git nicht mehr beängstigend.

Meine Meinung: Git erinnert sich an fast alles. Lerne die Befehle, die es dir erlauben, es zu fragen, und du wirst selten wieder Arbeit verlieren.

Desly