Das ultimative Git Cheat Sheet
Dieser Artikel wurde mit ChatGPT automatisch aus dem Englischen ins Deutsche übersetzt.
TLDR; Hol dir das Git Cheat Sheet als PDF oder Bild. Stelle sicher, dass Git installiert ist. Wir beginnen mit einem leeren Ordner, speichern unseren ersten Commit und arbeiten anschließend mit Branches, Merges und Remote-Repositories. Alle Befehle verwenden dasselbe kleine Projekt the-ultimate-git-cheat-sheet. So kannst du auch ohne Git-Erfahrung mitmachen. Den vollständigen Quellcode findest du auf GitHub. Wir haben die Tutorial-Branches dort absichtlich behalten, damit du sie erkunden und die Beispiele leichter nachvollziehen kannst.
Das ultimative Git Cheat Sheet herunterladen
Lade das Git Cheat Sheet herunter, um den Artikel Schritt für Schritt durchzuarbeiten. Teile es gerne mit deinen Kolleginnen, Kollegen und Freunden.
Möchtest du weitere Ressourcen wie diese?
Komm in unsere Community und melde dich für unseren Newsletter an, um bei DevOps auf dem Laufenden zu bleiben. Du erhältst unsere neuesten Ressourcen und Erkenntnisse direkt in dein Postfach!
Was ist Git?
Git ist ein verteiltes Versionskontrollsystem. Das klingt kompliziert, aber die Idee ist einfach: Git merkt sich Änderungen an deinen Dateien. Du kannst sehen, was sich geändert hat, frühere Versionen wiederherstellen und verschiedene Ideen ausprobieren, ohne dein gesamtes Projekt in Ordner wie final, final-2 und final-really-final zu kopieren.
Git ist verteilt, weil normalerweise jede Entwicklerin und jeder Entwickler eine vollständige Kopie der Projekthistorie besitzt. Du kannst ohne Internetverbindung Commits erstellen, den Verlauf ansehen und Branches anlegen. Ein gemeinsamer Server wird wichtig, wenn du zusammenarbeiten oder deine Arbeit sichern möchtest.
Git ist nicht dasselbe wie GitHub, GitLab oder Bitbucket. Git ist das Werkzeug zur Versionskontrolle auf deinem Rechner. Die anderen sind Hosting-Plattformen, die Git-Repositories speichern und Funktionen wie Pull Requests, Issues und CI/CD-Pipelines ergänzen.
Wie funktioniert Git?
Eine Änderung durchläuft in Git vier Bereiche:
- Arbeitsverzeichnis: Die Dateien, die du sehen und bearbeiten kannst.
- Staging-Bereich: Die Änderungen, die du für den nächsten Commit ausgewählt hast. Git nennt diesen Bereich auch Index.
- Lokales Repository: Die Commits im versteckten Verzeichnis
.gitauf deinem Rechner. - Remote-Repository: Eine gemeinsame Kopie auf einem anderen Rechner oder einer Plattform wie GitHub.
Der typische Ablauf lautet edit -> stage -> commit -> push: Du bearbeitest eine Datei, wählst Änderungen mit git add aus, speicherst mit git commit einen Snapshot und teilst die Commits mit git push.
working directory staging area local repository remote repository
edit -> git add -> git commit -> git push
Git speichert Snapshots statt einer losen Sammlung unabhängiger Dateiunterschiede. Hat sich eine Datei nicht geändert, kann Git auf den vorhandenen Inhalt verweisen, statt ihn erneut zu speichern.
Wie konfigurierst du Git?
Vor dem ersten Commit teilst du Git deinen Namen und deine E-Mail-Adresse mit. Beide werden Teil jedes Commits, den du erstellst.
# show the installed Git version
$ git --version
## => output
### git version 2.51.0
# set your identity for every repository on this machine
$ git config --global user.name "Ada Lovelace"
$ git config --global user.email "ada@example.com"
# use main as the initial branch name for new repositories
$ git config --global init.defaultBranch main
# list the effective configuration and where every value comes from
$ git config --list --show-origin
## => output
### file:/Users/ada/.gitconfig user.name=Ada Lovelace
### file:/Users/ada/.gitconfig user.email=ada@example.com
### file:/Users/ada/.gitconfig init.defaultbranch=main
# open the documentation for a command
$ git help commit
Lass --global weg, wenn eine Einstellung nur für das aktuelle Repository gelten soll. Das ist hilfreich, wenn du für Firmenprojekte eine berufliche und für Open-Source-Projekte eine private E-Mail-Adresse verwendest.
Was ist ein Git-Repository?
Ein Git-Repository ist ein Projektordner, in dem Git Änderungen an Dateien über die Zeit aufzeichnet. Er enthält deine normalen Projektdateien und das versteckte Verzeichnis .git. Darin liegen Commits, Branches, Tags und Konfiguration. Wenn du dieses Verzeichnis löschst, bleiben die Dateien erhalten, aber der Ordner ist kein Git-Repository mehr und die lokale Historie geht verloren.
Ein lokales Repository liegt auf deinem Computer. Ein Remote-Repository liegt auf einem anderen Rechner, etwa einem Server, und ist über eine URL erreichbar. Häufig wird es auf GitHub, GitLab oder Bitbucket gehostet. Mit git fetch lädst du Änderungen herunter, mit git push lädst du lokale Commits hoch. Für die Nutzung von Git brauchst du aber kein Remote-Repository.
Wie erstellst du ein neues Repository?
Wir erstellen das kleine Projekt the-ultimate-git-cheat-sheet. Dabei nutzen wir Git, um das Cheat Sheet selbst aufzubauen: Wir beginnen mit der README und ergänzen weitere Abschnitte in Feature-Branches.
# create and enter the project directory
$ mkdir the-ultimate-git-cheat-sheet
$ cd the-ultimate-git-cheat-sheet
# turn the current directory into a Git repository
$ git init
## => output
### Initialized empty Git repository in /Users/ada/the-ultimate-git-cheat-sheet/.git/
# inspect the current state
$ git status
## => output
### On branch main
###
### No commits yet
###
### nothing to commit (create/copy files and use "git add" to track)
Wie klonst du ein vorhandenes Repository?
Wenn ein Repository bereits auf einem Server existiert, kopierst du es mit git clone. Dabei werden Projektdateien, Historie und Remote-Konfiguration heruntergeladen.
# create a new directory named the-ultimate-git-cheat-sheet from a remote repository
$ git clone https://github.com/aichbauer/the-ultimate-git-cheat-sheet.git
$ cd the-ultimate-git-cheat-sheet
# show the local repository and its configured remote
$ git status
## => output
### On branch main
### Your branch is up to date with 'origin/main'.
###
### nothing to commit, working tree clean
$ git remote -v
## => output
### origin https://github.com/aichbauer/the-ultimate-git-cheat-sheet.git (fetch)
### origin https://github.com/aichbauer/the-ultimate-git-cheat-sheet.git (push)
Arbeite für dieses Tutorial mit dem Repository weiter, das du mit git init erstellt hast.
Was ist ein Commit in Git?
Ein Commit ist ein gespeicherter Snapshot deines Projekts. Er enthält die ausgewählten Änderungen, eine Nachricht, Autor, Datum und einen Verweis auf den Vorgänger-Commit. Git identifiziert jeden Commit mit einem Hash wie a1b2c3d.
Stell dir einen Commit wie einen Kontrollpunkt in einem Spiel vor. Er sollte einen verständlichen Schritt abbilden. Ein Commit namens Add branching command reference lässt sich leichter prüfen und wiederherstellen als ein Commit namens changes, der fünf unabhängige Aufgaben vermischt.
Ein Commit entsteht lokal. Er lädt nichts automatisch zu GitHub oder einem anderen Server hoch.
Wie erfasst und committest du Änderungen?
Normalerweise erstellst oder bearbeitest du Dateien, prüfst die Änderungen, übernimmst die passenden Änderungen in den Staging-Bereich und erstellst anschließend einen Commit. Du kannst mehrere Dateien gemeinsam vormerken und Dateien ausschließen, die Git ignorieren soll.
Wie erstellst du deinen ersten Commit?
Erstelle die erste Datei unseres Projekts und prüfe, wie Git sie sieht.
# create a small project file
$ printf "# The Ultimate Git Cheat Sheet\n\nA practical reference for everyday Git commands.\n" > README.md
# README.md is untracked: Git sees it but does not save it yet
$ git status
## => output
### On branch main
###
### No commits yet
###
### Untracked files:
### (use "git add <file>..." to include in what will be committed)
### README.md
###
### nothing added to commit but untracked files present (use "git add" to track)
# inspect unstaged changes
$ git diff
# select the file for the next commit
$ git add README.md
# inspect staged changes
$ git diff --staged
## => output
### diff --git a/README.md b/README.md
### new file mode 100644
### index 0000000..56546aa
### --- /dev/null
### +++ b/README.md
### @@ -0,0 +1,3 @@
### +# The Ultimate Git Cheat Sheet
### +
### +A practical reference for everyday Git commands.
# save the staged snapshot
$ git commit -m "Add project introduction"
## => output
### [main (root-commit) a1b2c3d] Add project introduction
### 1 file changed, 3 insertions(+)
### create mode 100644 README.md
git add bedeutet nicht „diese Datei für immer verfolgen“. Der Befehl kopiert den aktuellen Stand einer Änderung in den Staging-Bereich. Bearbeitest du die Datei danach erneut, musst du auch die neue Änderung vormerken.
Wie merkst du mehrere Änderungen vor?
Gehören mehrere Änderungen in denselben Commit, kannst du die Dateien einzeln angeben. git add . übernimmt alle geänderten oder noch nicht erfassten Dateien unterhalb des aktuellen Verzeichnisses in den Staging-Bereich.
# create a command reference and link to it from the README
$ printf "# Git Commands\n\nUseful Git commands for this project.\n" > commands.md
$ printf "\nSee commands.md for useful Git commands.\n" >> README.md
# stage several named files
$ git add README.md commands.md
# add a note and a simple workflow example
$ printf "Remember to review changes before committing.\n" > notes.md
$ mkdir examples
$ printf "git status\ngit add .\ngit commit\n" > examples/basic-workflow.txt
# stage changes below the current directory
$ git add .
# save all staged changes in one commit
$ git commit -m "Add Git command reference and examples"
## => output
### [main b2c3d4e] Add Git command reference and examples
### 4 files changed, 9 insertions(+)
### create mode 100644 commands.md
### create mode 100644 examples/basic-workflow.txt
### create mode 100644 notes.md
Wie ignorierst du Dateien?
Verwende eine .gitignore für generierte Dateien, Abhängigkeiten, Geheimnisse und Editor-Dateien, die nicht ins Repository gehören.
# create a local environment file with an example secret
$ printf "API_KEY=local-development-secret\n" > .env
# add ignore rules
$ printf ".env\nnode_modules/\n.DS_Store\n" > .gitignore
$ git add .gitignore
$ git commit -m "Ignore local and generated files"
## => output
### [main d4e5f6a] Ignore local and generated files
### 1 file changed, 3 insertions(+)
### create mode 100644 .gitignore
# check why a path is ignored
$ git check-ignore -v .env
## => output
### .gitignore:1:.env .env
Verlass dich nicht auf .gitignore, um bereits committete Geheimnisse zu schützen. Das Ignorieren einer erfassten Datei entfernt sie nicht aus der Historie. Ersetze offengelegte Zugangsdaten und bereinige die Historie bei Bedarf mit einem dafür vorgesehenen Werkzeug.
Was ist die Git-Historie?
Die Git-Historie ist die Kette der Commits in deinem Repository. Die meisten Commits haben einen Vorgänger; Merge-Commits können zwei oder mehr haben.
HEAD bezeichnet deine aktuelle Position. Meist zeigt HEAD auf den ausgecheckten Branch, der wiederum auf seinen neuesten Commit zeigt. HEAD~1 ist der erste Vorgänger des aktuellen Commits, HEAD~2 liegt zwei Generationen zurück.
Branches und Tags sind lesbare Namen für Commits. Der Commit-Hash bleibt die genaue Kennung.
Wie untersuchst und vergleichst du die Git-Historie?
Mit git log, git show und git blame untersuchst du Commits und ihre Herkunft. Mit git diff vergleichst du Dateien, Commits oder Branches.
Wie untersuchst du Commits?
# show the full commit history
$ git log
## => output
### commit d4e5f6a (HEAD -> main)
### Author: Ada Lovelace <ada@example.com>
### Date: Wed Aug 5 10:15:00 2026 +0200
###
### Ignore local and generated files
###
### commit b2c3d4e
### Author: Ada Lovelace <ada@example.com>
### Date: Wed Aug 5 10:10:00 2026 +0200
###
### Add Git command reference and examples
###
### commit a1b2c3d
### Author: Ada Lovelace <ada@example.com>
### Date: Wed Aug 5 10:00:00 2026 +0200
###
### Add project introduction
# show one compact line per commit
$ git log --oneline
## => output
### d4e5f6a (HEAD -> main) Ignore local and generated files
### b2c3d4e Add Git command reference and examples
### a1b2c3d Add project introduction
# show branches and merges as a graph
$ git log --oneline --graph --decorate --all
## => output
### * d4e5f6a (HEAD -> main) Ignore local and generated files
### * b2c3d4e Add Git command reference and examples
### * a1b2c3d Add project introduction
# inspect the first commit and explicitly show its patch
$ git show --patch HEAD~2
## => output
### commit a1b2c3d
### Author: Ada Lovelace <ada@example.com>
### Date: Wed Aug 5 10:00:00 2026 +0200
###
### Add project introduction
###
### diff --git a/README.md b/README.md
### new file mode 100644
### index 0000000..56546aa
### --- /dev/null
### +++ b/README.md
### @@ -0,0 +1,3 @@
### +# The Ultimate Git Cheat Sheet
### +
### +A practical reference for everyday Git commands.
# see who last changed every line in a file
$ git blame README.md
## => output
### a1b2c3d (Ada Lovelace 2026-08-05 10:00:00 +0200 1) # The Ultimate Git Cheat Sheet
### a1b2c3d (Ada Lovelace 2026-08-05 10:00:00 +0200 2)
### a1b2c3d (Ada Lovelace 2026-08-05 10:00:00 +0200 3) A practical reference for everyday Git commands.
### b2c3d4e (Ada Lovelace 2026-08-05 10:10:00 +0200 4)
### b2c3d4e (Ada Lovelace 2026-08-05 10:10:00 +0200 5) See commands.md for useful Git commands.
Wie vergleichst du Änderungen?
Mit git diff vergleichst du Arbeitsverzeichnis, Staging-Bereich und letzten Commit. In diesem Beispiel änderst du README.md, bewegst die Änderung durch die einzelnen Zustände und stellst die Datei anschließend wieder her. So ist das Projekt für das nächste Beispiel sauber. Die Ausgaben dienen der Veranschaulichung.
# add an unstaged line to the README
$ printf "\nExamples are available in the examples directory.\n" >> README.md
# unstaged changes: working directory versus staging area
$ git diff
## => output
### diff --git a/README.md b/README.md
### --- a/README.md
### +++ b/README.md
### @@ -1,5 +1,7 @@
### # The Ultimate Git Cheat Sheet
###
### A practical reference for everyday Git commands.
###
### See commands.md for useful Git commands.
### +
### +Examples are available in the examples directory.
# stage the README change
$ git add README.md
# inspect staged changes: staging area versus HEAD
$ git diff --staged
## => output
### diff --git a/README.md b/README.md
### --- a/README.md
### +++ b/README.md
### @@ -1,5 +1,7 @@
### # The Ultimate Git Cheat Sheet
###
### A practical reference for everyday Git commands.
###
### See commands.md for useful Git commands.
### +
### +Examples are available in the examples directory.
# add another unstaged line
$ printf "Review each command before running it.\n" >> README.md
# inspect staged and unstaged changes together
$ git diff HEAD
## => output
### diff --git a/README.md b/README.md
### --- a/README.md
### +++ b/README.md
### @@ -1,5 +1,8 @@
### # The Ultimate Git Cheat Sheet
###
### A practical reference for everyday Git commands.
###
### See commands.md for useful Git commands.
### +
### +Examples are available in the examples directory.
### +Review each command before running it.
# discard the example changes and return to the latest commit
$ git restore --staged README.md
$ git restore README.md
Was ist ein Branch in Git?
Ein Branch ist ein beweglicher Name, der auf einen Commit zeigt. Erstellst du einen Commit, wandert der aktuelle Branch auf diesen neuen Commit weiter. Das Anlegen eines Branches kopiert nicht das gesamte Projekt. Dadurch sind Branches klein und schnell erstellt.
Teams verwenden meist einen stabilen Branch namens main und kurzlebige Branches für Features oder Fehlerbehebungen. Dieser Ablauf bildet die Grundlage von Trunk-Based Development. Zwei Branches divergieren, wenn beide Commits enthalten, die im jeweils anderen fehlen.
Wie arbeitest du mit Git-Branches?
Ein typischer Ablauf ist: Branch erstellen und wechseln, eine klar abgegrenzte Änderung committen, zu main zurückwechseln, den fertigen Branch in main mergen und ihn anschließend löschen, wenn er nicht mehr benötigt wird.
Wie erstellst und wechselst du Branches?
Wir erstellen einen Feature-Branch und ergänzen eine Anleitung zu Branches, ohne main bereits zu verändern.
# list local branches; the current branch has an asterisk
$ git branch
## => output
### * main
# create a branch and switch to it
$ git switch --create feature/branching-guide
## => output
### Switched to a new branch 'feature/branching-guide'
# add the feature
$ printf "# Branching Guide\n\nUse short-lived branches for focused changes.\n" > branches.md
$ git add branches.md
$ git commit -m "Add branching guide"
## => output
### [feature/branching-guide b7c8d9e] Add branching guide
### 1 file changed, 3 insertions(+)
### create mode 100644 branches.md
# switch back to main
$ git switch main
## => output
### Switched to branch 'main'
# switch quickly to the previous branch
$ git switch -
## => output
### Switched to branch 'feature/branching-guide'
Wie vergleichst du Branches?
Sobald main und feature/branching-guide existieren, vergleichst du mit der Zwei-Punkt-Schreibweise die Snapshots an ihren Spitzen. Du kannst auch Commits anzeigen, die vom Feature-Branch aus erreichbar sind, aber nicht von main. Die Ausgaben dienen der Veranschaulichung.
# compare the files at the tips of both branches
$ git diff main..feature/branching-guide
## => output
### diff --git a/branches.md b/branches.md
### new file mode 100644
### --- /dev/null
### +++ b/branches.md
### @@ -0,0 +1,3 @@
### +# Branching Guide
### +
### +Use short-lived branches for focused changes.
# show commits reachable from the feature branch but not main
$ git log main..feature/branching-guide --oneline
## => output
### b7c8d9e (HEAD -> feature/branching-guide) Add branching guide
Wie benennst du Branches um und löschst sie?
Du kannst Branch-Namen verwalten, ohne zu den Branches zu wechseln.
# create a branch without switching
$ git branch feature/commit-guide
# rename a branch
$ git branch --move feature/commit-guide feature/commit-basics
# safely delete a fully merged branch
$ git branch --delete feature/commit-basics
## => output
### Deleted branch feature/commit-basics (was b7c8d9e).
# force-delete an unmerged branch - check its commits first
$ git branch --delete --force feature/abandoned-experiment
Was ist ein Merge in Git?
Ein Merge führt die Historien von Branches zusammen. Hat sich main seit dem Erstellen des Feature-Branches nicht verändert, kann Git einen Fast-Forward-Merge durchführen: main wird einfach auf den Feature-Commit verschoben.
# Before the merge, main has not advanced since feature branched
# and feature builds directly on the commit pointed to by main
A---B---C---D
^ ^
main feature
# After merging feature into main, both branches point to commit D
A---B---C---D
^
main, feature
Es entsteht kein Merge-Commit. Git verschiebt lediglich den Zeiger main von B auf D.
Enthalten beide Branches neue Commits, erstellt Git normalerweise einen Merge-Commit mit zwei Vorgängern. So bleibt erkennbar, dass zwei Entwicklungslinien zusammengeführt wurden.
# Before the merge
C---D feature
/
A---B---E---F main
# After merging, Git creates commit M with D and F as its parents
C---D-------\
/ \
A---B---E---F-------M main
merge commit
Der Merge-Commit M hat zwei Vorgänger: F, die bisherige Spitze von main, und D, die Spitze von feature.
Wie mergst du Git-Branches?
Merge die Branching-Anleitung in main.
# move to the branch that should receive the change
$ git switch main
## => output
### Switched to branch 'main'
# merge the feature into the current branch
$ git merge feature/branching-guide
## => output
### Updating d4e5f6a..b7c8d9e
### Fast-forward
### branches.md | 3 +++
### 1 file changed, 3 insertions(+)
### create mode 100644 branches.md
# inspect the result
$ git log --oneline --graph --decorate --all
## => output
### * b7c8d9e (HEAD -> main, feature/branching-guide) Add branching guide
### * d4e5f6a Ignore local and generated files
### * b2c3d4e Add Git command reference and examples
### * a1b2c3d Add project introduction
# remove the branch after the merge
$ git branch --delete feature/branching-guide
## => output
### Deleted branch feature/branching-guide (was b7c8d9e).
Wenn du während eines noch nicht abgeschlossenen Merges bemerkst, dass du auf dem falschen Branch bist, brich ihn vor dem Commit ab.
# return to the state before the unfinished merge
$ git merge --abort
Was ist ein Merge-Konflikt?
Ein Merge-Konflikt entsteht, wenn Git nicht sicher entscheiden kann, wie Änderungen zusammengeführt werden sollen. Das passiert häufig, wenn mehrere Personen parallel auf verschiedenen Branches dieselben Zeilen bearbeiten. Beispielsweise können main und ein Feature-Branch unterschiedliche Änderungen an derselben Zeile enthalten.
Den folgenden Konflikt erzeugen wir absichtlich zu Übungszwecken. Probiere ihn nur in diesem entbehrlichen Beispiel-Repository oder einem anderen sicheren Übungsprojekt aus. Er verändert die letzte Zeile von branches.md auf einem neuen Feature-Branch und auf main unterschiedlich.
# create a feature branch from main
$ git switch --create feature/branch-tips
# change the advice on the feature branch
$ printf "# Branching Guide\n\nKeep branches for future reference.\n" > branches.md
$ git add branches.md
$ git commit -m "Recommend keeping branches"
## => output
### [feature/branch-tips c8d9e0f] Recommend keeping branches
### 1 file changed, 1 insertion(+), 1 deletion(-)
# return to main and change the same line differently
$ git switch main
$ printf "# Branching Guide\n\nDelete branches after merging them.\n" > branches.md
$ git add branches.md
$ git commit -m "Recommend deleting merged branches"
## => output
### [main e9f0a1b] Recommend deleting merged branches
### 1 file changed, 1 insertion(+), 1 deletion(-)
# merge the feature branch into main
$ git merge feature/branch-tips
## => output
### Auto-merging branches.md
### CONFLICT (content): Merge conflict in branches.md
### Automatic merge failed; fix conflicts and then commit the result.
Git pausiert den Merge und markiert in branches.md beide Versionen:
# Branching Guide
<<<<<<< HEAD
Delete branches after merging them.
=======
Keep branches for future reference.
>>>>>>> feature/branch-tips
Der erste Teil stammt aus dem aktuellen Branch, der zweite aus dem Branch, der hineingemergt wird. Trennlinie und Markierungen gehören nicht zum gültigen Dateiinhalt. Du musst die gewünschte Fassung auswählen oder kombinieren.
Wie löst du einen Merge-Konflikt?
Lege den endgültigen Text fest, entferne die Konfliktmarkierungen und merke die bereinigte Datei vor. Hier kombinieren wir die sinnvollen Aussagen beider Versionen.
# see every conflicted file
$ git status
## => output
### On branch main
### You have unmerged paths.
### (fix conflicts and run "git commit")
### (use "git merge --abort" to abort the merge)
###
### Unmerged paths:
### (use "git add <file>..." to mark resolution)
### both modified: branches.md
###
### no changes added to commit (use "git add" and/or "git commit -a")
Öffne branches.md im Editor. Entferne die Markierungen und die unerwünschten Versionen. Bearbeite den Text, bis die Datei so aussieht:
# Branching Guide
Delete branches after merging them unless your team needs to retain them.
# mark the conflict as resolved
$ git add branches.md
# verify the staged resolution
$ git diff --staged
## => output
### diff --git a/branches.md b/branches.md
### index 7ac83a1..e49bf6c 100644
### --- a/branches.md
### +++ b/branches.md
### @@ -1,3 +1,3 @@
### # Branching Guide
###
### -Delete branches after merging them.
### +Delete branches after merging them unless your team needs to retain them.
# finish the merge
$ git commit -m "Merge branch retention guidance"
## => output
### [main f0a1b2c] Merge branch retention guidance
# remove the merged feature branch
$ git branch --delete feature/branch-tips
Führe deine Tests aus, bevor du den Merge abschließt. Auch eine Datei ohne Konfliktmarkierungen kann noch falsches Verhalten enthalten.
# cancel an unresolved merge instead of completing it
$ git merge --abort
Was ist ein Remote-Git-Repository?
Ein Remote-Repository ist ein anderes Git-Repository, das dein lokales Repository unter einem Kurznamen kennt. Beim Klonen richtet Git das Quell-Repository normalerweise automatisch als Remote namens origin ein.
Ein lokales Repository kann mehrere Remotes mit unterschiedlichen Namen haben. In einem Fork-Workflow bezeichnet origin häufig deinen Fork und upstream das ursprüngliche Repository. Das sind Konventionen, keine besonderen Git-Schlüsselwörter.
Ein Remote-Tracking-Branch wie origin/main hält den Stand von main fest, den dein lokales Git zuletzt von origin erhalten hat. Ein Upstream-Branch ist der Remote-Branch, den ein lokaler Branch standardmäßig für Pull und Push verwendet.
Wie arbeitest du mit Remote-Repositories?
Verbinde zunächst das lokale Repository mit einem Remote und veröffentliche deine Commits. Später holst du Änderungen mit Fetch oder Pull, um deinen lokalen Stand aktuell zu halten.
Wie fügst du ein Remote hinzu und pushst dorthin?
Erstelle vor diesen Befehlen ein neues, leeres Repository in deinem GitHub-Konto. Initialisiere es nicht mit README, .gitignore oder Lizenz, da dein lokales Projekt bereits eine eigene Historie besitzt. Ersetze in der URL <your-account> durch deinen GitHub-Kontonamen und <your-repository> durch den Namen des neuen Repositories.
# add a remote named origin
$ git remote add origin https://github.com/<your-account>/<your-repository>.git
# inspect remote names and URLs
$ git remote -v
## => output
### origin https://github.com/<your-account>/<your-repository>.git (fetch)
### origin https://github.com/<your-account>/<your-repository>.git (push)
$ git remote show origin
# publish main and remember origin/main as its upstream
$ git push --set-upstream origin main
# publish later commits
$ git push
Wie holst du Änderungen mit Fetch und Pull?
git fetch lädt Remote-Commits herunter und aktualisiert die Remote-Tracking-Branches, ohne deinen aktuellen Branch zu ändern. git pull führt zunächst Fetch aus und integriert anschließend den Upstream-Branch in deinen aktuellen Branch.
# download remote information without changing local files
$ git fetch origin
# compare the local and remote main branches
$ git log --oneline main..origin/main
$ git diff main..origin/main
# fetch and merge the upstream branch
$ git pull
# fetch and rebase local commits onto the upstream branch
$ git pull --rebase
Zuerst zu fetchen macht den Ablauf übersichtlicher: Du kannst eingehende Commits prüfen, bevor du sie integrierst.
Wo findest du das Git Cheat Sheet für Fortgeschrittene?
Dieses Cheat Sheet konzentriert sich auf Befehle für den typischen Arbeitsalltag. Im Git Cheat Sheet für Fortgeschrittene lernst du Stash, Rebase, Cherry-Pick, Tags, Bisect, Reflog, Worktrees und Submodule kennen.
Fazit
Wir haben mit einem leeren Verzeichnis begonnen und ein praktisches Verständnis von Git aufgebaut. Du kannst jetzt Commits erstellen, die Historie untersuchen, mit Branches arbeiten, Konflikte lösen und über Remote-Repositories zusammenarbeiten.
Die sicherste Git-Gewohnheit ist einfach: Prüfe den Zustand, bevor du etwas änderst. Nutze regelmäßig git status, git diff und git log und erstelle kleine Commits mit klaren Nachrichten.
Wenn du Unterstützung bei deinen DevOps-Abläufen brauchst, kontaktiere uns gerne. Oder komm für Fragen und Diskussionen in unsere Community – kostenlose Kekse für die ersten 42 Mitglieder, und nur noch 6 sind übrig 😱!
Komm in unsere CommunityHat dir dieser Artikel gefallen? Teile ihn mit deinen Kolleginnen, Kollegen und Freunden.
Melde dich für unseren Newsletter an!
Verpasse keine neuen Tipps, Anleitungen und Updates – melde dich jetzt für unseren Newsletter an! Wir schicken dir nur relevante und hilfreiche Informationen. Entdecke mit uns die Welt von Git, DevOps und darüber hinaus.
Mit deiner Anmeldung akzeptierst du die Datenschutzerklärung. Du kannst dich jederzeit über den Link am Ende unserer E-Mails abmelden.