Git: Basics - wichtigste Befehle erklärt

By PierreAdmin , 4 October 2026

Git Terminologie / Git Begriffe

Kürzel im Git-Baum:
- M = modified
- A = added
- D = deleted
Repository:
Das Repository ist der Speicherort, in dem Git alle Versionen und Änderungen eines Projekts speichert. Es kann sich um ein lokales Repository auf dem Computer oder ein entferntes Repository auf einem Git-Server handeln.
branch:
Ein Branch ist eine Zweigstelle in einem Git-Repository, die es ermöglicht, unabhängig von anderen Entwicklungen an neuen Funktionen oder Änderungen zu arbeiten, ohne die Hauptentwicklungslinie zu beeinflussen.
origin:
Standardname für das externe Repository. Es ist quasi das Alias für die URL des remote (in der Regel gitlab, github) Repositorys. Mittels push, pull oder fetch wird damit interagiert.
commit:
Ein Commit ist ein Snapshot oder eine Momentaufnahme des Codes zu einem bestimmten Zeitpunkt im Repository. Es protokolliert die Änderungen, die gemacht wurden, und enthält eine eindeutige Kennung (ID) Die Kurzform wird in git stage und anderen Befehlen (z.B. git log usw.) als 7-stelliger Wert angezeigt. Z.B.: 362841d.
clone:
Das Klonen ist der Vorgang, bei dem ein bestehendes Git-Repository kopiert wird, um eine vollständige Kopie des Codes und der History zu erstellen. In der Regel clont man ein Projekt von gitlab/github auf seine lokale Arbeitsumgebung.
push:
Push ist der Vorgang, bei dem das letzte lokale Commit ins remote (origin) Repository geladen wird.
pull:
Pull ist der Vorgang, bei dem Änderungen aus dem remote (origin) Repository heruntergeladen und ins lokale Repository integriert werden. Nach dem pull hat das lokale Repository den Stand von origin/main (oder entsprechendem branch)
fetch:
Fetch lädt das aktuelle remote (origin) Repository herunter, um den Zustand des origin und lokalen Repositories zu vergleichen. Wichtig: Es werden keine Daten irgendwo damit geändert.
checkout: (z.T. veraltet)
Checkout ist der Vorgang, um zu einem bestimmten Commit, Branch oder Tag zu wechseln, um mit einer anderen Version des Codes zu arbeiten. Aktuell ändert man Branches mit switch.
Working directory (Arbeitsverzeichnis):
Das Working Directory ist der Ordner auf dem lokalen Computer, in dem an den Dateien und Projekten gearbeitet wird. Es enthält die aktuelle Version des Codes.
Staging Area:
Die Staging-Area ist ein Zwischenspeicher, in dem die Änderungen vor dem Commiten hingeschoben werden. Daten die in der Staging Area liegen, können auch wieder zurückgeholt werden, um den Stand vor dem add Befehl wieder herzustellen.
Untracked files:
Dateien die neu hinzugefügt wurden und noch nicht geaddet wurden, oder mittels .gitignore ausgeschlossen sind.

Hilfe

git help: Zeigt gesamtes Manual an
git help <Befehl>: Zeigt explizit die Hilfe für den entsprechenden Befehl an.

Kurzschreibweise

im Manual steht z.B. 
-A, --all, --no-ignore-removal
    Update the ...

Alle durch Komma getrennten Eingaben, machen genau das gleiche. -A ist die Kurzform (short option), --all und --no-ignore-removal die Langform (long option).

Git einrichten

init
- ```
git init 
```
  - erstellt ein neues Projekt im aktuellen Verzeichnis und erzeugt ein unsichtbares .git Verzeichnis
config
- Damit wird git konfiguriert. Mit --global bleibt die Konfiguration für sämtliche Git-Projekte gespeichert. Es müssen also nicht jedesmal Name, defaultBranch (main) oder E-Mail eingegben werden.
- ```
git config --global init.defaultBranch main
git confit --global user.email mail@per-net.ch
git config --global user.name Pierre Meyer
```
  - Erzeugt in den globalen Einstellungen den Standardbranch main. Früher war das meistens master. Die Settings müssen nur einmal gemacht werden. Darin stehen z.B. auch Name und E-Mail von mir und können via git config --list aufgerufen werden
- ```
git config --list 
git config --list --show-origin 
```
  - zeigt die Konfiguration an. --show-origin zeigt dabei zuätzlich noch den Pfad zum remote Repository.
remote
- add
  - Definiert die Verbindung zum externen Repository. origin ist dabei der Name/Platzhalter für das externe Repository.
    git@ = ist die Anmeldung bei gitlab. Man meldet sich immer als git@ an.
    @gitlab = Kurzname aus .ssh/config für die ssh Verbindung zu gitlab
    :URL dahinter folgt die url des Projektes auf gitlab
    - ```
    git remote add origin git@gitlab:GITLAB-PROJEKTPFAD
```
- Nur für den ersten commit:
  - ```
  git push -u origin main
```
- set-url
  - Bestehende URL ändern
    - ```
    git remote set-url origin git@gitlab:GITLAB-PROJEKTPFAD 
```
add
- Schiebt Dateien in die Stage-Area
- ```
git add <filename1> <filename2> 
```
  - Staged eine oder mehrere Dateien.
- ```
git add . 
```
  - Staged Änderungen ab dem aktuellen Verzeichnis abwärts, aber nicht oberhalb dieses Verzeichnisses. Darum nutze ich konsequent git add -A.
- ```
git add -A
```
  - Staged alle Änderungen im gesamten Repository (vom Root aus), egal in welchem Unterverzeichnis man sich befindet.
commit
- Verschiebt die gestageten Files ins Repository
- ```
git commit -m 'Kommentar zum Commit' 
```
  - schiebt alle gestagten Files ins Repository. Wird kein Kommentar geschrieben öffnet sich der Standardeditor.
- ```
git commit --amend          öffnet vi mit best. Kommi
git commit --amend -m       normal mit Kommifeld
git commit --no-edit        wenn Kommi vorher ok war
```
  - schreibt einen neuen Commit und löscht dabei den letzten. Sehr hilfreich, wenn man nach dem Commit einen kleinen Fehler bemerkt, der eigentlich keinen neuen Commit bräuchte. Man vermeidet damit unnötig viele kleine und unbedeutende commits wie z.B. «File vergessen, Fehler übersehen, etc.
    WICHTIG: Die Funktion darf nur angewendet werden, solange noch kein push ausgeführt wurde. Beim push reklarmiert remote, dass ein neuer commit kommt, aber letzte durch --amend gelöschte fehlt. Da blockt remote, weil der gelöschte commit auf remote da ist, auf lokal aber fehlt. > Fixen kann man das Problem trotzdem mit git reset --soft origin/main.
log
zeigt die ausführliche History aller gemachten Commits an.
- ```
git log --oneline -10 
```
  - listet die letzten Commits in Kurzform in einer Zeile auf. Optional: -10
- ```
git log -10 --date=short --pretty=format:'%h %ad %s'
```
  - listet die letzten 10 auf
    --date=short (definiert das Datumsformat 2026-12-25),
    --pretty=format (definiert den Output: %h kurzer hash, %ad Autor Datum %an Autor Name, %s 1. Commitzeile
branch
- ```
git branch
```
  - zeigt die aktuellen Branches an. Der mit * markierte Branch ist der aktuell gewählte.
- ```
git branch <branch-name> 
```
  - Erzeugt einen neuen Branch.
- ```
git branch -d <branch-name>
```
  - Löscht einen Branch
merge
- ```
git merge <branch-name>
```
- Damit werden die Änderungen aus dem aufgerufenen Branch übernommen.
  WICHTIG: Man muss sich im Branch befinden, in den man den merge einfügen will.
reset
- ```
git reset
```
  - die staging area wird zurückgesetzt. Alle Dateien ungestaged. Die Staging Area wird dabei aber nicht einfach geleert, sondern auf den Stand von HEAD zurückgesetzt.
    REMINDER: HEAD bezeichnet den aktuellen Stand des letzten Commits.
- ```
git reset --soft origin/main
```
  - Damit wird der letzte Stand von origin/main wieder hergestellt. Die gemachten Änderungen bleiben erhalten, somit auch wieder als M (modified) markiert.
restore
- ```
git restore <filename>
```
  - Damit lassen sich gestagede Dateien wieder zurückholen.
    WICHTIG: Funktioniert nur mit gestageten Dateien. Nach einem Commit funktioniert restore nicht.
revert
- ```
git revert <hash>
```
  - Dieser Befehl macht einen Commit rückgängig. Zuvor sucht man den entsprechenden Commit mit git log --oneline oder git log --oneline --parents um den Hash des gesuchten Commits zu sehen. --parents zeigt immer den davorliegenden Hash an, auf dessen Stand revert zurück geht und dabei gleich einen aktuellen neuen Commit anlegt.
    Nach ausführen von revert wird der Texteditor mit der neuen Commitmeldung geöffnet. Bei mir in der Regel vi. Zum Schliessen :wq.
    
    ACHTUNG: Wird an einer Datei die den Commit betroffen hat später weitere Commits gemacht, fehlt unter umständen relevantes.
    Beispiel dazu:
  - ```
  Commit 443: Datei A hat "Hallo"
  Commit 444: Datei A geändert zu "Hallo Welt"  ← revert hierauf
  Commit 445: Datei A geändert zu "Hallo Welt heute"
  Commit 446: aktuell
```
  - git revert 444 erstellt einen neuen Commit der die Änderung von 444 rückgängig macht – also entfernt " Welt" aus dem Text.
  - Aber: Die Änderung von 445 (" heute") bleibt! Das Ergebnis wäre dann "Hallo heute" – was wahrscheinlich nicht das gewünschte Resultat ist.
switch (alter Befehl checkout: funktioniert immer noch)
- Wechselt in einen anderen Branch
- ```
git switch <branch-name>
```
  - Wechselt zum gewählten Branch
  - Die Änderungen die im aktiven Branch gemacht werden haben keinen Einfluss auf den main Branch, oder umgekehrt. Um die Änderungen in den main branch zu übernehmen verwendet man den merge Befehl.

OLD STUFF

Dieser Bereich ist alt und nicht mehr gültig und muss noch überarbeitet werden:

git stash push Schiebt alle gemachten Änderungen in ein «verstecktes (stash)» Verzeichnis, um es später wieder zu nutzen. Es räumt quasi gemachte Änderungen in einen Zwischenspeicher. Der Grund für ein solches Vorgehen ist mir im Moment noch unklar, bzw. wie und wo so etwas gebraucht wird. In der Erklärung wird gesagt, dass man so Varianten ausprobieren kann ...
Der Stash-Befehl funktioniert nur für gestagte Files. Neue Dateien müssen erst geaddet werden.
git stash pop bringt die Änderungen wieder ins Working Directory und löscht dabei den Stash.
git stash drop bringt die Änderungen wieder ins Working Direkctory, lässt sie aber im Stash stehen.
git stash list zeigt alles stashes an
git stash clear löscht Stash
git clone git@gitlab.com:per.net/pierres-test-project.git
WICHTIG: Wenn man mit SSH arbeitet, muss der Git-Code unter «CODE» > Clone with SSH kopiert werden. Der Link der in der README-Datei steht ist der HTTPS Code. Dieser Code funktioniert nicht mit SSH.
In meinem Testbeispiel wird das Test Projekt «Pierres Test Project» in das bestehende Projekt geladen. Im Unterordner «pierres-test-project» ist der .git Ordner vom Gitlab Projekt. Aktuell gibt es also zwei Repositories, die ineinander liegen. Wie das Zusammenzuführen ist, weiss ich noch nicht.

Ende des zu überarbeitenden Bereiches

Git