Git Stage und Commit meistern: Ihre ersten Änderungen

Die Grundlagen von Git Stage und Commit zu beherrschen, ist der erste echte Schritt, um Git selbstbewusst zu nutzen. Staging ermöglicht es Ihnen, genau auszuwählen, was in den nächsten Snapshot aufgenommen wird, und ein Commit zeichnet diesen Snapshot mit einer Nachricht auf, die zukünftige Leser verstehen können.

Wenn Sie jeden Commit als kleine, überprüfbare Arbeitseinheit behandeln, wird Git viel einfacher zu verwenden. Sie können Änderungen überprüfen, unzusammenhängende Bearbeitungen aufteilen und Fehler ohne Panik beheben.

Wie der Staging-Bereich funktioniert

Git committet nicht automatisch jede von Ihnen bearbeitete Datei. Es trennt Ihre Arbeit in den Arbeitsbaum, den Staging-Bereich und die Commit-Historie.

Der Arbeitsbaum ist Ihr Projektordner. Dies sind die Dateien, die Sie in Ihrem Editor bearbeiten.

Der Staging-Bereich ist Git's Checkliste für den nächsten Commit. Wenn Sie git add ausführen, speichern Sie noch keine Historie. Sie wählen Änderungen für den nächsten Commit aus.

Die Repository-Historie ist die Sequenz der bereits aufgezeichneten Commits.

Überprüfen Sie zunächst den Status:

git status

Git zeigt nicht verfolgte Dateien, geänderte Dateien, gestaffelte Änderungen und Ihren aktuellen Branch an. Dieser Befehl kann jederzeit sicher ausgeführt werden und sollte zur Gewohnheit werden.

Um eine neue oder geänderte Datei zu stagen:

git add README.md

Um alle Änderungen im aktuellen Verzeichnis zu stagen:

git add .

Dieser Befehl ist praktisch, aber verwenden Sie ihn vorsichtig. Er kann nicht zusammenhängende Dateien, lokale Konfigurationen oder generierte Ausgaben stagen, wenn Ihre .gitignore unvollständig ist.

Für eine sicherere Überprüfung zeigen Sie zuerst den Diff an:

git diff

Stagen Sie dann nur das, was zusammengehört:

git add src/app.js
git add README.md

Nach dem Staging überprüfen Sie, was committet wird:

git diff --staged

Dies zeigt den genauen gestaffelten Snapshot. Wenn etwas falsch aussieht, korrigieren Sie es vor dem Commit.

Ihren ersten Commit erstellen

Sobald die richtigen Änderungen gestaffelt sind, erstellen Sie einen Commit:

git commit -m "Projekt-README hinzufügen"

Die Nachricht sollte die Änderung beschreiben, nicht die von Ihnen durchgeführte Aktion. "Projekt-README hinzufügen" ist nützlicher als "Änderungen" oder "Dateien aktualisieren".

Ein guter Commit hat normalerweise einen klaren Zweck. Angenommen, Sie aktualisieren ein Bereitstellungsskript und korrigieren auch einen Tippfehler auf einer Dokumentationsseite. Das sind separate Änderungen. Stagen und committen Sie sie separat:

git add scripts/deploy.sh
git commit -m "Gesundheitscheck für Bereitstellung hinzufügen"

git add docs/setup.md
git commit -m "Tippfehler im Setup-Leitfaden korrigieren"

Dies erleichtert die Überprüfung. Es erleichtert auch das Zurücksetzen, wenn die Bereitstellungsänderung ein Problem verursacht, die Dokumentationskorrektur jedoch in Ordnung ist.

Wenn Sie git commit ohne -m ausführen, öffnet Git Ihren Editor. Das ist nützlich, wenn Sie eine längere Nachricht benötigen:

Gesundheitscheck für Bereitstellung hinzufügen

Überprüfen Sie den Service-Endpunkt, bevor Sie die Bereitstellung als abgeschlossen markieren.
Dies hilft, fehlgeschlagene Starts früher im Release-Prozess zu erkennen.

Die erste Zeile sollte kurz und direkt sein. Der Körper kann erklären, warum die Änderung erforderlich war oder Kompromisse erwähnen.

Um die letzten Commits anzuzeigen:

git log --oneline -5

Dies gibt Ihnen eine kompakte Ansicht der letzten Historie.

Teile einer Datei stagen

Manchmal enthält eine Datei mehrere nicht zusammenhängende Bearbeitungen. Git kann mit dem Patch-Modus nur einen Teil einer Datei stagen:

git add -p src/config.js

Git zeigt jeden Änderungs-Hunk und fragt, was zu tun ist. Häufige Optionen sind:

• y: diesen Hunk stagen.
• n: diesen Hunk nicht stagen.
• s: den Hunk in kleinere Teile aufteilen, wenn möglich.
• q: Patch-Modus beenden.

Patch-Staging ist nützlich, wenn Sie vor einem Commit aufräumen. Zum Beispiel könnten Sie eine Datei haben, in der Sie eine neue Timeout-Einstellung hinzugefügt und auch einen Kommentar umformatiert haben. Stagen Sie die Timeout-Änderung für einen Commit, dann stagen Sie die Kommentarbereinigung für einen anderen.

Wenn Sie versehentlich etwas gestaged haben, heben Sie das Staging auf, ohne Ihre Arbeit zu verwerfen:

git restore --staged src/config.js

Ihre Datei bleibt im Arbeitsbaum geändert. Sie wird lediglich aus dem Staging-Bereich entfernt.

Wenn Sie nicht gestaffelte Änderungen in einer Datei verwerfen möchten, seien Sie vorsichtig:

git restore src/config.js

Dieser Befehl verwirft lokale Bearbeitungen in dieser Datei. Führen Sie zuerst git diff aus, damit Sie wissen, was Sie verlieren.

Weitere Wiederherstellungsmuster finden Sie unter Git-Fehler rückgängig machen.

Commit-Hygiene für die tägliche Arbeit

Kleine, fokussierte Commits sind einfacher zu überprüfen, zu testen und rückgängig zu machen. Sie machen auch Werkzeuge wie git bisect nützlicher, wenn Sie herausfinden müssen, wo ein Fehler begonnen hat.

Verwenden Sie diese Gewohnheiten:

• Führen Sie git status vor dem Staging aus.
• Überprüfen Sie git diff vor git add.
• Überprüfen Sie git diff --staged vor dem Commit.
• Halten Sie nicht zusammenhängende Änderungen in separaten Commits.
• Schreiben Sie Nachrichten, die erklären, was geändert wurde.
• Vermeiden Sie es, generierte Dateien zu committen, es sei denn, das Projekt erwartet sie.
• Committen Sie niemals Geheimnisse, private Schlüssel oder lokale .env-Werte.

Ein praktischer Workflow könnte so aussehen:

git status
git diff
git add src/server.js
git diff --staged
git commit -m "Fehlende Gesundheitscheck-Antwort behandeln"
git status

Diese Sequenz ist nicht spektakulär, fängt aber die meisten Anfängerfehler. Sie wissen, was geändert wurde, was gestaged ist, was committet wurde und was übrig bleibt.

Wenn Ihr Team Pre-Commit-Hooks oder automatisierte Formatierung verwendet, kann ein Commit fehlschlagen, bis Sie die Formatierung oder Tests korrigieren. Lesen Sie die Fehlermeldung, führen Sie den vorgeschlagenen Befehl aus, stagen Sie die resultierenden Änderungen und committen Sie erneut.

Wann Sie um Hilfe bitten sollten

Bitten Sie um Hilfe, wenn Sie versehentlich Geheimnisse gestaged oder committet haben, wenn Sie im falschen Branch committet haben oder wenn Sie unsicher sind, ob Sie amendieren, revertieren, zurücksetzen oder einen neuen Commit erstellen sollen. Diese Optionen haben unterschiedliche Auswirkungen, insbesondere nach einem Push.

Sie sollten auch fragen, bevor Sie Commits umschreiben, die andere möglicherweise gepullt haben. Eine einfache lokale Bereinigung kann zu einem Teamproblem werden, wenn sie die gemeinsame Historie ändert.

Staging und Committen sind die Kernschleife von Git. Überprüfen Sie Ihre Änderungen, stagen Sie absichtlich, committen Sie in fokussierten Teilen und schreiben Sie Nachrichten, die auch in einem Monat noch Sinn ergeben.