Git-Tutorial: die Basisbefehle (add, commit, push, pull)

Fünf Befehle reichen für die tägliche Arbeit: status, add, commit, push und pull. Dieses Kapitel nimmt sie einzeln durch und kommt dann zu dem, was kein Tutorial auslassen sollte: wie du zurückkommst, wenn du dich vertan hast.

Eine Voraussetzung: deine Identität muss hinterlegt sein, sonst verweigert Git deinen ersten Commit. Falls das noch fehlt, geh zurück zum Installationskapitel.

Die drei Bereiche von Git

Vieles wird einfacher, sobald klar ist, dass deine Dateien in einem von drei Bereichen liegen.

• Das Arbeitsverzeichnis: deine Dateien so, wie du sie im Dateimanager siehst.
• Der Index, auch Staging Area genannt: die Liste dessen, was in den nächsten Commit wandert. git add legt Änderungen dort ab.
• Das Repository: die Commit-Historie, die git commit füttert.

Dieser Zwischenbereich irritiert am Anfang, aber genau er erlaubt es, drei von fünf Änderungen festzuhalten und die beiden anderen für einen eigenen Commit aufzuheben.

git status, der Befehl, den du ständig brauchst

Er sagt dir, wo du stehst, und seine Meldungen enthalten fast immer den nächsten Befehl gleich mit. Gewöhn dir an, ihn vor und nach jeder Operation abzusetzen.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.env
	app.js
	node_modules/

nothing added to commit but untracked files present (use "git add" to track)

Die Kurzfassung passt in eine Zeile pro Datei und wird schnell zum Reflex:

git status --short

?? .env
?? app.js
?? node_modules/

?? steht für eine Datei, die Git noch nicht verfolgt, A für eine Datei im Index, M für eine geänderte Datei.

.gitignore: was niemals mitgehen darf

Noch vor dem ersten git add sortierst du aus, was in einem Repository nichts verloren hat: neu installierbare Abhängigkeiten, Konfigurationsdateien mit Geheimnissen, alles, was dein System oder dein Editor erzeugt.

Leg dazu im Projektstamm eine Datei .gitignore an:

node_modules/
vendor/
.env
.env.local
dist/
build/
*.log
.DS_Store
.idea/
.vscode/

Ruf git status erneut auf: die ignorierten Dateien sind aus der Liste verschwunden.

?? .gitignore
?? app.js

Die .gitignore selbst wird versioniert: sie gehört zum Projekt und muss mit dem Team geteilt werden.

Achtung, eine Falle: .gitignore hat keinerlei Wirkung auf eine Datei, die bereits verfolgt wird. Wenn du eine .env committet hast, bevor du daran gedacht hast, musst du sie ausdrücklich aus dem Index nehmen:

git rm --cached .env
git commit -m "Retire le fichier .env du suivi"

Die Option --cached ist entscheidend: sie nimmt die Datei aus dem Index, ohne sie von deiner Platte zu löschen.

Und betrachte die Geheimnisse darin als kompromittiert: in der Historie bleiben sie lesbar. Tausch sie aus.

git add: den Commit vorbereiten

git add app.js          # eine Datei
git add src/            # ein ganzer Ordner
git add .               # alles, was sich unter dem aktuellen Ordner geändert hat
git add -p              # Block für Block auswählen, interaktiv

git add -p lohnt sich früh. Git zeigt dir jeden Änderungsblock einzeln und fragt, ob er in den Commit soll. Einfacher kommst du nicht zu Commits, die genau eine Sache erzählen.

git commit: festhalten

git commit -m "Ajoute la page d'accueil"

[main (root-commit) fd4fdb7] Ajoute la page d accueil
 2 files changed, 3 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 app.js

Ist der Index leer, legt Git nichts an und sagt es dir:

On branch main

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Zu Commit-Nachrichten lohnt eine einzige Regel: schreib, was der Commit tut, nicht was du angefasst hast. „Korrigiert die Mehrwertsteuer bei Bestellungen außerhalb der EU“ ist besser als „Änderung facture.php“. Du schreibst für dich selbst in sechs Monaten.

Die Abkürzung -am kombiniert add und commit, aber nur für bereits verfolgte Dateien:

git commit -am "Corrige le libellé du bouton"

Die Historie lesen

git log                                  # vollständig
git log --oneline                        # eine Zeile pro Commit
git log --oneline --graph --decorate     # mit dem Verlauf der Branches
git log -p app.js                        # die Historie einer einzelnen Datei, mit den Diffs

* fd4fdb7 (HEAD -> main) Ajoute la page d accueil

HEAD bezeichnet die Stelle, an der du dich in der Historie befindest. Der Pfeil zeigt, dass HEAD dem Branch main folgt.

Seine Änderungen vor dem Commit ansehen

Zwei Befehle, die oft verwechselt werden und zwei verschiedene Bereiche betrachten.

git diff            # was geändert, aber noch nicht im Index ist
git diff --staged   # was im Index liegt und in den nächsten Commit geht

diff --git a/app.js b/app.js
index e921523..ebde020 100644
--- a/app.js
+++ b/app.js
@@ -1 +1 @@
-console.log('hello');
+console.log('bonjour');

Nach einem git add app.js wechselt dieselbe Änderung die Seite: git diff gibt nichts mehr aus, git diff --staged zeigt den Block. Besser lässt sich der Index nicht sichtbar machen.

git push und git pull: mit dem Server austauschen

git push        # die lokalen Commits senden
git pull        # die der anderen holen und einbinden

Diese beiden Kurzformen funktionieren nur, wenn der Branch mit dem Server verknüpft ist, dafür sorgt das -u aus dem vorigen Kapitel. So prüfst du diese Verknüpfung:

git branch -vv

* feature/panier bc2203a Page d accueil
  main           bc2203a [origin/main] Page d accueil

Der Branch main folgt origin/main, der Branch feature/panier folgt vorerst nichts.

Hat jemand gepusht, während du gearbeitet hast, wird dein push abgelehnt. Das Vorgehen und die vollständige Erklärung stehen im Kapitel über Branches.

Mist wieder geradebiegen

Das ist der Teil, nach dem Einsteiger am häufigsten suchen und der ihnen am seltensten erklärt wird. Der richtige Reflex besteht darin, zuerst eine Frage zu beantworten: Ist das, was ich rückgängig machen will, schon auf dem Server gelandet?

Die Datei ist geändert, ich will zurück zum letzten Commit

git restore app.js       # eine Datei
git restore .            # das gesamte Arbeitsverzeichnis

Achtung, dieser Befehl vernichtet deine Änderungen ohne Netz: sie wurden nirgends festgehalten, Git kann sie nicht wiederfinden.

Ich habe zu schnell git add getippt

git restore --staged app.js

Die Datei verlässt den Index, deine Änderungen bleiben im Arbeitsverzeichnis unangetastet.

Diese beiden Befehle sind das moderne Gegenstück zu git checkout -- fichier und git reset HEAD fichier. git restore gibt es seit Git 2.23 und es sagt klar, was es tut, während checkout und reset je nach Option drei verschiedene Dinge tun.

Die Nachricht meines letzten Commits taugt nichts

git commit --amend -m "Le bon message"

Derselbe Befehl dient dazu, eine vergessene Datei nachzuschieben: mach dein git add und ruf dann git commit --amend auf. Setz ihn nur auf einem Commit ein, der noch nicht gepusht wurde: --amend ändert den Commit nicht, er legt an seiner Stelle einen neuen an, und die alte ID verschwindet.

Der Commit ist schon gepusht, ich will ihn sauber zurücknehmen

git revert HEAD

[main 0246de1] Revert "Ajoute un fichier par erreur"
 1 file changed, 1 deletion(-)
 delete mode 100644 bug.txt

git revert erzeugt einen neuen Commit, der das Gegenteil des vorigen anwendet. Die Historie wird länger, statt umgeschrieben zu werden, und genau das brauchst du, wenn andere deine Arbeit bereits geholt haben. Auf einem geteilten Branch ist es die einzige gefahrlose Methode.

Der Commit ist nicht gepusht, ich will ihn löschen

git reset --soft HEAD~1   # macht den Commit rückgängig, behält alles im Index
git reset --mixed HEAD~1  # macht den Commit rückgängig, behält die Dateien geändert (Standardverhalten)
git reset --hard HEAD~1   # macht den Commit rückgängig und löscht die Änderungen

--soft ist am nützlichsten: du bekommst deine Änderungen zurück, bereit für einen anderen Commit. --hard ist die einzige Variante, die Arbeit vernichtet, und sie warnt nicht vorher. Tipp sie nur, wenn du sicher bist.

Ich habe einmal zu viel reset –hard gemacht

Nicht alles ist verloren. Git bewahrt mehrere Wochen lang die Spur aller Zustände auf, die HEAD durchlaufen hat:

git reflog

8207e54 HEAD@{0}: reset: moving to HEAD~2
f3951da HEAD@{1}: commit: Version 3
8ac671c HEAD@{2}: commit: Version 2
8207e54 HEAD@{3}: commit (initial): Version 1

Die beiden gelöschten Commits sind noch da. Such die Zeile mit dem gewünschten Zustand, notier ihre ID und geh dorthin zurück:

git reset --hard f3951da

Das reflog rettet allerdings nur, was committet worden war. Nie festgehaltene Änderungen sind endgültig weg, ein Argument mehr dafür, oft zu committen.

Die Zusammenfassung

Du kannst allein arbeiten. Das nächste Kapitel nimmt die anderen dazu: Branches, Merges und Konflikte. Das letzte Kapitel behandelt danach, wie sich diese Branches im Maßstab eines Teams organisieren lassen.