Git Commands Cheat Sheet: The 20 Commands You Actually Need — cod-ai.com

Die Produktionskrise um 3 Uhr morgens, die verändert hat, wie ich Git lehre

Es war 3:17 Uhr an einem Dienstag, als mein Telefon mit Benachrichtigungen explodierte. Unser Hauptproduktionszweig war kaputt, Bereitstellungen schlugen fehl, und niemand konnte herausfinden, was schiefgelaufen war. Ich war der leitende DevOps-Ingenieur im Dienst, und als ich zu meinem Laptop taumelte, wusste ich genau, was passiert war – jemand hatte gewaltsam in den Hauptzweig gepusht, ohne zu verstehen, was er tat.

Dieser Vorfall kostete uns etwa 47.000 USD an verlorenen Einnahmen während des vierstündigen Ausfalls. Aber wichtiger ist, dass er mir etwas Wichtiges beigebracht hat: Die meisten Entwickler müssen tatsächlich nicht 200 Git-Befehle kennen. Sie müssen etwa 20 Befehle meistern und sie tief genug verstehen, um katastrophale Fehler zu vermeiden.

Ich bin Marcus Chen und arbeite seit 12 Jahren als DevOps-Ingenieur und technischer Leiter, hauptsächlich bei mittelgroßen bis großen SaaS-Unternehmen. Ich habe über 150 Entwickler eingearbeitet, Tausende von Pull-Requests überprüft und mehr Git-Desaster beseitigt, als ich mich erinnern möchte. Was ich gelernt habe, ist, dass Git-Meisterschaft nicht darin besteht, jedes Flag und jede Option auswendig zu lernen – es geht darum, ein zuverlässiges mentales Modell zu haben und genau zu wissen, welche Befehle in bestimmten Situationen aufzurufen sind.

Dieses Handout stellt die destillierte Weisheit aus über einem Jahrzehnt praktischer Git-Nutzung dar. Das sind keine theoretischen Befehle, die ich in der Dokumentation gefunden habe. Das sind die 20 Befehle, die ich fast täglich benutze, die ich jedem neuen Teammitglied beibringe und die meinem Team unzählige Stunden Frustration erspart haben. Jeder Befehl hier hat sich durch praktische Notwendigkeit seinen Platz verdient, nicht durch akademische Vollständigkeit.

Bevor wir eintauchen, lasse mich klarstellen: Das hier ist keine Einführung für Anfänger in Git. Wenn du völlig neu in der Versionskontrolle bist, solltest du woanders mit den Grundlagen beginnen. Dieser Leitfaden ist für Entwickler gedacht, die bereits wissen, dass es Git gibt und es verwendet haben, aber ihre Effizienz und ihr Selbstvertrauen steigern möchten. Du bist es leid, dieselben Befehle immer wieder zu googeln. Du möchtest ein kuratiertes, kampferprobtes Nachschlagewerk, das tatsächlich widerspiegelt, wie Profis Git in Produktionsumgebungen verwenden.

Die Grundlagen: Befehle, die du jeden einzelnen Tag verwenden wirst

Fangen wir mit den absoluten Essentials an – den Befehlen, die das Rückgrat deines täglichen Git-Workflows bilden. Ich verwende diese Befehle so häufig, dass sie praktisch Muskelgedächtnis sind. Wenn du in einem Team jeglicher Größe arbeitest, wirst du wahrscheinlich jeden dieser Befehle mindestens einmal pro Tag verwenden, oft sogar mehrfach.

"Git-Meisterschaft besteht nicht darin, jedes Flag und jede Option auswendig zu lernen – es geht darum, ein zuverlässiges mentales Modell zu haben und genau zu wissen, welche Befehle in bestimmten Situationen aufzurufen sind."

git status — Das ist dein Kommando für situative Wahrnehmung. Ich führe diesen Befehl wahrscheinlich 30-40 Mal pro Tag aus, und ich übertreibe nicht. Bevor du committest, nachdem du committest, wenn sich etwas falsch anfühlt, wenn du zwischen Aufgaben wechselst – git status sagt dir genau, wo du stehst. Er zeigt dir, welche Dateien bereitgestellt, welche verändert, aber nicht bereitgestellt und welche nicht verfolgt werden. Betrachte es als deinen Git-Kompass. Die Ausgabe ist farblich kodiert und bemerkenswert klar, weshalb dies der erste Befehl ist, den ich jedem beibringe.

git add — Dies stellt deine Änderungen für den Commit bereit. Die häufigste Verwendung ist git add ., um alles in deinem aktuellen Verzeichnis bereitzustellen, aber ich empfehle tatsächlich, selektiver zu sein. Verwende git add dateiname, um spezifische Dateien bereit zu stellen, oder git add -p für interaktives Staging, bei dem du einzelne Änderungen überprüfen und bereitstellen kannst. Diese granulare Kontrolle hat mich unzählige Male gerettet, wenn ich mehrere nicht zusammenhängende Änderungen vorgenommen habe und sie separat committen musste. Nach meiner Erfahrung erstellen Entwickler, die git add nachlässig verwenden, unordentliche Commit-Historien, die das Debuggen und die Code-Überprüfung erheblich erschweren.

git commit -m "Nachricht" — Dies erstellt einen Snapshot deiner bereitgestellten Änderungen. Das -m-Flag ermöglicht es dir, eine Commit-Nachricht direkt hinzu zu fügen. Jetzt, hier ist, wo ich einige hart erarbeitete Weisheiten teilen werde: Deine Commit-Nachrichten sind weit wichtiger, als du denkst. Ich habe Stunden damit verbracht, zu verstehen, warum eine bestimmte Änderung vorgenommen wurde, nur um eine Commit-Nachricht zu finden, die "Dinge reparieren" oder "Updates" sagt. Eine gute Commit-Nachricht sollte diesen Satz vervollständigen: "Wenn angewendet, wird dieses Commit ...". Zum Beispiel: "Wenn angewendet, wird dieses Commit die Benutzer-Authentifizierung zum Anmeldeendpunkt hinzufügen." Diese Disziplin hat die Code-Archäologie für meine Teams unendlich einfacher gemacht.

git push — Dies lädt deine lokalen Commits in das Remote-Repository hoch. Am häufigsten verwendest du git push origin branch-name. Beim ersten Push einer neuen Branch musst du git push -u origin branch-name verwenden, wobei das -u-Flag das Tracking einrichten, sodass zukünftige Pus sämtliche git push sein können. Ich kann das nicht genug betonen: Verwende niemals git push --force auf gemeinsamen Branches, es sei denn, du weißt absolut, was du tust und hast mit deinem Team kommuniziert. Der Vorfall um 3 Uhr morgens, den ich erwähnt habe? Das war ein fehlerhafter Force-Push.

git pull — Dies holt Änderungen aus dem Remote-Repository und merged sie in deinen aktuellen Branch. Ich beginne jede Arbeitssitzung mit einem git pull, um sicherzustellen, dass ich mit dem neuesten Code arbeite. Eine kritische Sache, die du verstehen musst: git pull ist tatsächlich zwei kombinierte Befehle – git fetch gefolgt von git merge. Manchmal möchtest du diese separat verwenden, um mehr Kontrolle zu haben, was wir später besprechen werden. Wenn du pullst und es Konflikte gibt, wird dir Git genau sagen, welche Dateien Konflikte haben, und du musst sie manuell lösen, bevor du fortfahren kannst.

Branching: Dein Paralleluniversum-Werkzeugkasten

Branching ist, wo die wahre Stärke von Git zum Vorschein kommt. Es ermöglicht mehreren Entwicklern, gleichzeitig an verschiedenen Funktionen zu arbeiten, ohne sich gegenseitig in die Quere zu kommen. In meinem aktuellen Team von 23 Entwicklern haben wir typischerweise 40-60 aktive Branches zu jedem Zeitpunkt. Das Meistern dieser Branching-Befehle trennt die gelegentlichen Git-Nutzer von den selbstbewussten Profis.

git branch — Führe