Git |

Installation von Git

Mon, 01 Jan 0001 00:00:00 +0000

# Linux / macOS
kurse$ git --version
git version 2.33.0

# Windows
PS kurse> git --version
git version 2.33.0.windows.2

Wird statt einer Versionsangabe eine Fehlermeldung angezeigt, dass das git Befehl nicht gefunden wurde, muss git zuerst installiert werden.

Der Befehl “git” ist entweder falsch geschrieben oder konnte nicht gefunden werden.

Folgen Sie dazu der Installationsanleitung für Ihr Betriebssystem von der offiziellen .

Initialisierung eines lokalen Repositorys

Mon, 01 Jan 0001 00:00:00 +0000

Hinweis

Als ein Repository bei git wird ein Ordner bezeichnet, der unter Versionskontrolle von git steht.

Ordner anlegen

Als erstes legen wir einen Ordner an, den wir gleich unter die Versionsverwaltung stellen wollen. Aktuell werden wir es mit einem leeren Ordner tun, das Gleiche lässt sich auch mit einem vorhandenen Ordner erledigen, wenn Sie desen Inhalt versionieren wollen.

Wechseln Sie in den neu erzeugten Ordner.

# Linux / macOS
src$ mkdir repo_1
src$ ls -la
repo_1
src$ cd repo_1

# Windows (Power Shell Core)
PS src> New-Item repo_1 -Type Directory

 Directory: C:\Users\kurse\src

Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 15.09.2021 08:05 repo_1
PS src> cd repo_1

Repository initialisieren

Nun initialisieren wir ein git Repository mit dem init¹ Befehl von git.

# Linux / macOS
repo_1$ git init
Initialized empty Git repository in /Users/kurse/src/repo_1/.git/
$ ls -la
total 0
drwxrwxrwx 1 kurse kurse 4096 Sep 15 08:10 .
drwxrwxrwx 1 kurse kurse 4096 Sep 15 08:05 ..
drwxrwxrwx 1 kurse kurse 4096 Sep 15 08:10 .git

# Windows (Power Shell Core)
PS repo_1> git init
Initialized empty Git repository in C:/Users/kurse/src/repo_1/.git/
PS repo_1> Get-ChildItem . -Force

 Directory: C:\Users\kurse\src\repo_1

Mode LastWriteTime Length Name
---- ------------- ------ ----
d--h- 15.09.2021 08:12 .git

Dabei wird das Verzeichnis unter Versionskontrolle gestellt. Das ist an dem versteckten Ordner .git gut zu sehen. In diesem werden alle Informationen zu den Versionen gespeichert.

Prüfen des aktuellen Zustandes von Repository

Den aktuellen Zustand des Ordners, aus Sicht von git, können wir mit dem Befehl status² abrufen. Dieser zeigt, ob neue Dateien zu der Versionsverwaltung hinzugefügt werden können, ob geänderte Dateien vorliegen usw.

# Linux / macOS
repo_1$ git status
On branch main

No commits yet

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

# Windows
PS repo_1> git status
On branch main

No commits yet

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

Bei einem neu angelegten Repository ist der Status sauber. Es sind ja keine Dateien versioniert und es liegen keine zum Versionieren vor.

↩︎
↩︎

Eine Datei versionieren

Mon, 01 Jan 0001 00:00:00 +0000

Legen wir eine neue Text-Datei an, die wir versionieren möchten.

# Linux / macOS
repo_1$ touch kapitel_1.txt

# Windows
PS repo_1> New-Item kapitel_1.txt

 Directory: C:\Users\kurs\src\repo_1

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 21.09.2021 07:32 0 kapitel_1.txt

Wenn wir nun den Status des Repositorys aufrufen, erhalten wir eine ganz andere Meldung.

repo_1$ git status
On branch main

No commits yet

Untracked files:
 (use "git add <file>..." to include in what will be committed)
 kapitel_1.txt

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

Datei zum Staging-Bereich hinzufügen

Die Meldung besagt, dass in unserem Ordner eine neue, noch nicht versionierte (untracked) Datei liegt. Git gibt zugleich auch den Tipp, wie diese Datei unter Versionskontrolle genommen werden kann. Wir folgen einfach dem Tipp und nutzen den add¹ Befehl. Mit status prüfen wir wieder, welche Auswirkung das auf unser Repository hat.

repo_1$ git add kapitel_1.txt
repo_1$ git status
On branch main

No commits yet

Changes to be committed:
 (use "git rm --cached <file>..." to unstage)
 new file: kapitel_1.txt

Nun besagt die Meldung, dass wir Änderungen haben, die auf ein Commit warten.

Änderungen festschreiben

Hinweis

Commit bei git ist eine Aktion, mit der der aktuelle Stand als Version gespeichert wird. Zu einem Commit müssen die betroffenen Dateien vorgemerkt werden. Dieses Vormerken wird auch Staging genannt.

Nun schreiben wir die Version mit einen commit² endgültig fest. Dabei ist es bei git auch immer notwendig eine Nachricht mitzugeben (Parameter -m), die die aktuelle Version beschreibt. Eine gute Dokumentation, wie eine Commit-Nachricht aussehen könnte, finden Sie unter .

Wird die Nachricht (Message) nicht direkt mit angegeben, startet git automatisch vorkonfigurierten Text-Editor, um die Nachricht in diesem einzugeben. Das ist sehr praktisch, wenn man mehrzeilige Nachrichten an die Version anhängen möchte.

repo_1$ git commit -m "feat: Start des ersten Kapitels"

*** Please tell me who you are.

Run

 git config --global user.email "you@example.com"
 git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <kurse@pc.localdomain>) not allowed

Benutzer in git einrichten

Warnung

Nutzten Sie git zum ersten Mal, erscheint eine Fehlermeldung, dass git uns noch nicht kennt. Git benötigt immer den Namen und die E-Mail-Adresse des Benutzers, um diese in der Versionshistorie zu nutzen. In der Fehlermeldung steht auch, wie der Fehler korrigiert werden kann.

repo_1$ git config --global user.email "kurse@richter.consulting"
repo_1$ git config --global user.name "Eugen [WebDucer] Richter"
repo_1$ git commit -m "feat: Start des ersten Kapitels"
[main (root-commit) e12fb6d] feat: Start des ersten Kapitels
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 kapitel_1.txt

Jetzt haben wir unseren ersten Commit mit git erstellt. Mit git status kann nachgeprüft werden, ob das Repository nun wieder in einen sauberen Zustand ist.

Allgemeiner Ablauf

Der allgemeine Ablauf beim Arbeiten mit git sieht damit wie folgt aus:

Anlegen oder ändern der Dateien, die versioniert werden sollen.
Hinzufügen der neuen oder geänderten Dateien über git add dateiA dateiB.
Festschreiben der neuen Version mit git commit -m "Warum wurde etwas geändert".

↩︎
↩︎

Historie anzeigen lassen

Mon, 01 Jan 0001 00:00:00 +0000

Die Historie eines Repositorys kann über den Befehl log¹ angesehen werden. Dieser gibt eine sehr ausführliche Information über alle gemachten Commits. Der Befehl hat viele Parameter und kann sehr gut angepasst werden (was wir später noch nutzen werden).

repo_1$ git log
commit e12fb6dc6e0b69af839d95efff837ecebf7e443f (HEAD -> main)
Author: Eugen [WebDucer] Richter <kurse@richter.consulting>
Date: Tue Sep 21 08:06:48 2021 +0200

 feat: Start des ersten Kapitels

Verkürzte Anzeige der Historie

Wenn die Anzahl der Commits steigt, wird die ausführliche Ausgabe der Historie sehr unübersichtlich. Mit dem Parameter --pretty=oneline² kann die Ausgabe pro Commit auf eine Zeile reduziert werden.

repo_1$ git log --pretty=oneline
e12fb6dc6e0b69af839d95efff837ecebf7e443f (HEAD -> main) feat: Start des ersten Kapitels

Mit den Parametern --oneline --decorate wird die Ausgabe noch kürzer. Dabei wird der Commit-Hash auf 7 Zeichen gekürzt (statt 32). Die Kürzung ist für die meisten Repositorys unproblematisch und weiterhin eindeutig.

repo_1$ git log --oneline --decorate
e12fb6d (HEAD -> main) feat: Start des ersten Kapitels

Aliases

Da man die langen Befehle mit vielen Parametern nicht jedes Mal aus dem Gedächtnis herauskramen will, bietet git die Möglichkeit, diese mit einem Alias (alternativen Namen) zu versehen. Wir vergeben für unsere Log-Anzeige ein Alias³ pl (für pretty log).

repo_1$ git config --global alias.pl 'log --graph --oneline --decorate --all'

Das Alias wir dabei in der globalen (--global) Konfiguration von git gespeichert.

log: git Befehl, in unserem Fall log
--graph: Darstellung des Logs als Graph (dazu später mehr, wenn wir mehr als ein branch haben)
--oneline: Einzeilige Darstellung
--decorate: Hübsche Darstellung der Zeile
--all: Alle Branches anzeigen, nicht nur das aktuelle (später mehr dazu)

Nun können wir mit dem einfachen git pl das Log mit vielen Parametern einfach aufrufen.

repo_1$ git pl
* e12fb6d (HEAD -> main) feat: Start des ersten Kapitels

↩︎
↩︎
↩︎

Ausnahmen für Versionierung

Mon, 01 Jan 0001 00:00:00 +0000

Es kommt oft vor, das in dem Ordner nicht nur Dateien liegen, die versioniert werden sollen, sondern auch andere (eventuell temporäre) Dateien. Bei der Software-Entwicklung sind es zum Beispiel die kompilierten Binärdateien, oder auch sehr viele temporäre. Auch Office hinterlegt oft temporäre Dateien, wenn man das Original bearbeitet.

Legen wir eine temporäre Datei an, die wir nicht in der Versionsverwaltung haben wollen, zum Beispiel mit dem Namen kapitel_1.~ und kapitel_1.bak.

# Linux / macOS
repo_1$ touch kapitel_1.~ kapitel_1.bak
repo_1$ ls
kapitel_1.bak kapitel_1.txt kapitel_1.~

# Windows
PS repo_1> New-Item -ItemType File -Path "kapitel_1.~", "kapitel_1.bak"

 Directory: C:\Users\kurs\src\repo_1

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 28.10.2021 08:50 0 kapitel_1.~
-a--- 28.10.2021 08:50 0 kapitel_1.bak

Wenn wir jetzt git status aufrufen, sehen wir zwei noch nicht versionierte Dateien. Das wollen wir eigentlich nicht sehen, da diese Dateien uns nicht interessieren.

repo_1$ git status
On branch main
Untracked files:
 (use "git add <file>..." to include in what will be committed)
 kapitel_1.bak
 kapitel_1.~

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

Globale Ausnahmen (Betriebssystem)

Git bietet für solche Dateien zwei Orte, in denen die Ausnahmen definiert werden können. Wir können die Ausnahmen global (auf Benutzerebene) definieren, oder pro Repository.

Um eine neue Ausnahmedatei für den Benutzer anzulegen, geben Sie Folgendes ein:

# Linux / macOS
repo_1$ git config --global core.excludesfile ~/.gitignore_global
repo_1$ touch ~/.gitignore_global

# Winfows
PS repo_1> git config --global core.excludesfile "$env:USERPROFILE\.gitignore_global"
PS repo_1> New-Item "$env:USERPROFILE\.gitignore_global"

 Directory: C:\Users\kurs

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 11.11.2021 19:47 0 .gitignore_global

Nun kann in die betreffende Datei .gitignore_global¹ die Liste der globalen Ausnahmen gepflegt werden. Fügen Sie in unserem Fall einfach Folgendes als erste Zeilen in die Datei ein:

# Ignore global backup files
*.bak

Die Zeilen, die mit # Anfangen, werden als Kommentare ausgewertet.

Eine sehr gute Übersicht über übliche Ausnahmen liefert die Seite . Im Verzeichnis Global sind dabei die globalen Ausnahmen für unterschiedliche Betriebssysteme (z.B. bei macOS ist es üblich die Datei .DS_Store auszufiltern, oder unter Windows Thumbs.db).

Pro Zeile in der Datei wird eine Ausnahme definiert, die auch Globings (Platzhalter) erlaubt.

*: Beliebiges Zeichen, beliebige Anzahl
**: Beliebige Unterverzeichnisse
?: Ein Zeichen
[Aa]: Regex für kleines/großes A
!abc: Mit ! kann die Ausnahme umgekehrt werden (zum Beispiel alles im Ordner XYZ nicht versionieren, aber die Datei abc.md)

Nach dem Hinzufügen der oberen Ausnahme können wir wieder mit git status unsere Bemühungen überprüfen.

repo_1$ git status
On branch main
Untracked files:
 (use "git add <file>..." to include in what will be committed)
 kapitel_1.~

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

Nun wir die Datei kapitel_1.bak nicht mehr angezeigt.

Ausnahmen im Repository

Die Ausnahmen für ein konkretes Repository werden in der Datei .gitignore² definiert. Meistens wird diese Datei in die Versionsverwaltung aufgenommen, da diese Ausnahmen das konkrete Projekt betreffen und für alle Beteiligten relevant sind.

Die Datei .gitignore gilt dabei für das aktuelle Verzeichnis und alle Unterverzeichnisse. Unterverzeichnisse können dabei eigene Ausnahmen in eigenen .gitignore Dateien definieren, die die Ausnahmen aus den übergeordneten Verzeichnissen ergänzen.

Legen Sie nun die .gitignore Datei im Wurzelverzeichnis von unserem Repository.

# Linux / macOS
repo_1$ touch .gitignore

# Windows
PS repo_1> New-Item .gitignore

 Directory: C:\Users\kurs\src\repo_1

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 11.11.2021 19:53 0 .gitignore

Fügen Sie in die neue Ausnahmedatei folgende Zeilen, um unsere .~ Datei von der Versionsverwaltung auszuschließen.

# Exclude temporal files
*.~

Mit git status sehen wir nun, dass auch die .~ Datei in der Auflistung nicht mehr auftaucht, dafür aber unsere neue .gitignore Ausnahmedatei. Diese sollen wir versionieren.

repo_1$ git status
On branch main
Untracked files:
 (use "git add <file>..." to include in what will be committed)
 .gitignore

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

repo_1$ git add .gitignore
repo_1$ git commit -m "Add repo ignore file for temp files"
[main c3b4e8b] Add repo ignore file for temp files
 1 file changed, 1 insertion(+)
 create mode 100644 .gitignore

Auf der bereits erwähnten finden Sie eine Sammlung von Ausnahmedateien für unterschiedliche Projekte (Programmiersprachen / Tools). Sie müssen damit die Ausnahmelisten nicht selbst erstellen, sondern von dieser Seite die vorhandenen als Ausgangsbasis für eigene Projekte nutzen.

↩︎
↩︎

Änderungen zwischen Version anzeigen

Mon, 01 Jan 0001 00:00:00 +0000

Wenn man mit der Zeit eine Versionshistorie aufgebaut hat, kommt der Zeitpunkt, wenn man zwei Versionen einer Datei miteinander vergleichen möchte. Dazu bietet git den Befehl diff¹ an, der mit einigen Parametern gesteuert werden kann.

Legen wir zuerst ein paar Commits mit Änderungen an, damit etwas zum Anschauen haben. Aktuell ist unsere Datei kapitel_1.txt leer.

Commit 1
- Inhalt
```
# Kapitel 1
Es war ein Mal...
```
- Message: Kapitel 1 der Geschichte starten
Commit 2
- Inhalt
```
Viele Jahre später ...
```
- Message: Fortsetzung in vielen Jahren

Commit 3

Inhalt

Nach 20 Jahren treffen sich die Freunde wieder.
Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.

Message: Treffen nach 20 Jahren

Am Ende sollte der Inhalt der Datei wie folgt aussehen.

# Kapitel 1
Es war ein Mal...
Viele Jahre später ...
Nach 20 Jahren treffen sich die Freunde wieder.
Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.

Und die Historie mit unserem Alias pl sollte in etwa wie folgt aussehen (die Hashwerte sind bei Ihnen natürlich ganz anders).

repo_1$ git pl
* e4c2672 (HEAD -> main) Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Aktuelle Änderungen zeigen

Ruft man den Befehl git diff <Dateiname> ohne weitere Parameter auf, zeigt dieses die aktuellen Änderungen an, also was sich seit dem letzTen Commit in der Datei geändert hat. Rufen Sie es mit einer Datei, die keine Änderungen hat, gibt der Befehl nichts aus.

Ohne einen Dateinamen werden die Änderungen vom kompletten Repository angezeigt. Die Anzeige erfolgt dabei im DIFF Format. Die neuen Zeilen werden über ein + vor der Zeile angezeigt, entferne mit einem -.

Ändern Sie nun unsere Datei kapitel_1.txt wie folgt, ohne die Änderungen in die Versionsverwaltung festzuschreiben:

Entfernen Sie die Zeile 3 (Viele Jahre später ...)

Fügen Sie nach der Zeile 3 folgendes ein

Sie verabredeten sich in ihrem alten Kaffee zu treffen,
dass sie immer nach der Schule besucht haben.

Der text sollte nun wie folgt aussehen:

# Kapitel 1
Es war ein Mal...
Nach 20 Jahren treffen sich die Freunde wieder.
Sie verabredeten sich in ihrem alten Kaffee zu treffen,
dass sie immer nach der Schule besucht haben.
Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.

Rufen Sie nun den Befehl git diff auf (mit oder ohne den Dateinamen).

repo_1$ git diff kapitel_1.txt
diff --git a/kapitel_1.txt b/kapitel_1.txt
index 20f47a6..8cc2eca 100644
--- a/kapitel_1.txt
+++ b/kapitel_1.txt
@@ -1,5 +1,6 @@
 # Kapitel 1
 Es war ein Mal...
-Viele Jahre später ...
 Nach 20 Jahren treffen sich die Freunde wieder.
+Sie verabredeten sich in ihrem alten Kaffee zu treffen,
+dass sie immer nach der Schule besucht haben.
 Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.
\ No newline at end of file

Wir sehen hier in DIFF Format, dass eine Zeile (nach “Es war ein Mal…”) entfernt wurde, und zwei Zeilen (zwischen “Nach 20 Jahren treffen sich die Freunde wieder.” und “Das Kaffee, dass damals an diesem Platz stand, existiert nicht mehr.”) dazu gekommen sind.

Diese Anzeige zeigt den Unterschied zwischen dem letzten Commit und der aktuellen Arbeitsversion.

Unterschiede zwischen zwei Commits

Wollen wir die Datei zwischen zwei bestimmten Versionen (Commits) vergleichen, müssen wird das diff Commando mit wenigen Parametern erweitern. Die sehr umfangreiche Liste der möglichen Parameter kann mit git diff --help aufgerufen werden. Uns interessieren aktuell nur die zwei gängigsten, bei denen die zwei Anker mit angegeben werden. Ein Anker kann dabei ein Commit, ein Branch oder ein Tag sein.

Als Erstes können wir explizit zwei Commit angeben, die wir miteinander vergleichen wollen. Die Commit-Hashes können wir sehr einfach mit unserem git pl Alias anzeigen lassen.

repo_1$ git pl
* e4c2672 (HEAD -> main) Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels
repo_1$ git diff c3b4e8b bd4b2df
diff --git a/kapitel_1.txt b/kapitel_1.txt
index e69de29..61a6fe5 100644
--- a/kapitel_1.txt
+++ b/kapitel_1.txt
@@ -0,0 +1,3 @@
+# Kapitel 1^M
+Es war ein Mal...^M
+Viele Jahre später ...
\ No newline at end of file

`HEAD` Anker für `diff` nutzen

Wenn Sie in der Historie nur wenige Commits zurückgehen wollen, lässt sich das auch mit dem HEAD Zeiger erledigen. HEAD steht immer auf dem letzten Commit. Mit der ^ und ~x Syntax kann man vom HEAD aus 1 oder x Commits zurückgehen. Das obere Ergebnis erreichen wir also auch mit dem folgenden Befehl (ohne die Commit-Hashes zu kennen).

repo_1$ git diff HEAD~3 HEAD^ kapitel_1.txt
diff --git a/kapitel_1.txt b/kapitel_1.txt
index e69de29..61a6fe5 100644
--- a/kapitel_1.txt
+++ b/kapitel_1.txt
@@ -0,0 +1,3 @@
+# Kapitel 1^M
+Es war ein Mal...^M
+Viele Jahre später ...
\ No newline at end of file

Reihenfolge ist wichtig

Passen Sie auf die Reihenfolge auf. Im Normalfall interessiert Sie, was seit einem bestimmten Commit passiert ist, die Reihenfolge der Parameter ist also älterer Commit und dann neuerer. Wenn Sie die Parameter vertauschen, erhalten Sie die Ansicht, was müsste gemacht werden, um den ursprünglichen Zustand wieder zu erhalten.

repo_1$ git diff HEAD^ HEAD~3 kapitel_1.txt
diff --git a/kapitel_1.txt b/kapitel_1.txt
index 61a6fe5..e69de29 100644
--- a/kapitel_1.txt
+++ b/kapitel_1.txt
@@ -1,3 +0,0 @@
-# Kapitel 1
-Es war ein Mal...
-Viele Jahre später ...
\ No newline at end of file

Schreiben Sie nun die letzte, noch nicht festgeschriebene Änderung an unserer Datei fest.

Hinweis

Damit wir nicht jedes Mal zwei Befehle ausführen müssen (add + commit), können wir beides kombinieren. Dabei werden alle geänderten / gelöschten Dateien in das Stating-Bereich übernommen und in den Commit aufgenommen. Neue Dateien (die noch nicht unter Versionsverwaltung stehen) werden dabei nicht berücksichtigt. Diese müssen zuerst mit git add hinzugefügt werden.

/repo_1$ git commit -a -m "Korrekturen am Kapitel 1"
[main 027c2f3] Korrekturen am Kapitel 1
 1 file changed, 2 insertions(+), 1 deletion(-)

Der Parameter -a (oder auch in der Langschreibweise --all) führt zu der gewollten Aktion.

↩︎

Verzweigungen (Branches) anlegen

Mon, 01 Jan 0001 00:00:00 +0000

Früher oder später braucht man mehr als nur eine lineare Entwicklung auf einen einzigen Zweig. Der einfachste Ansatz dazu, ist mit main und develop Zweigen zu arbeiten. Dabei erfolgt auf dem develop Zweig die eigentliche Entwicklung. Auf dem main Zweig landen dann die auslieferungsfähige Versionen, die oft auch benannt werden (Tags - siehe übernächstes Kapitel).

Branches anzeigen

Verschafen wir uns zuerst die Übersicht über die aktuell im Repository vorhandenen Zweige (Branches).

repo_1$ git branch
* main

Wir haben aktuell also nur den Branch main. Mit dem * wird bei mehreren Branches immer das aktuell aktive markiert.

Hinweis

Eventuell sehen Sie statt main einen master als Brnachnamen. Das hängt davon ab, wann Sie git auf Ihrem System installiert haben. Falls Sie eine ältere Installation haben, können Sie die globale Konfiguration mit folgender Zeile umstellen:

git config --global init.defaultBranch main

Den vorhandenen master Branch können Sie auch jederzeit auf neue Konvention umstellen.

git branch -m master main

Branches anlegen

Nun legen wir einen neuen Brnach an, den wir develop nennen. Dazu wird der Befehl branch <neuer_name>¹ genutzt.

repo_1$ git branch develop
repo_1$ git branch
 develop
* main

Zum Branch wechseln

Um nun auf den neuen Branch arbeiten zu können, wecheln wir zu diesem mit dem checkout² Befehl.

repo_1$ git checkout develop
Switched to branch 'develop'
repo_1$ git branch
* develop
 main

Nun können wir auf diesem Zweig unsere Änderungen durchführen und festschreiben. Führen Sie für den nächsten Schritt nun folgende Schritte durch:

Legen Sie eine neue die Datei kapitel_2.txt an
Versionieren Sie diese

Fügen Sie folgenden Text zu der Datei:

# Kapitel 2
Nach einer durchzechten Nacht ...

Schreiben Sie die Änderung in der Historie fest
Legen Sie eine neue Datei kapitel_3.txt an, ohne diese unter Versionsverwaltung zu stellen.

Am Ende sollte die Historie (und Status) in etwa wie folgt aussehen:

repo_1$ git pl
* aac4d8b (HEAD -> develop) Nachtszene
* e6b896a Ideen zum zweiten Kapitel
* 027c2f3 (main) Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels
repo_1$ git status
On branch develop
Untracked files:
 (use "git add <file>..." to include in what will be committed)
 kapitel_3.txt

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

Branch Verhalten

Jetzt haben wir zwei neue Dateien im Branch develop erstellt. Dabei haben wir eine davon unter die Versionsverwaltung (kapitel_2.txt). In dem Ordner liegen aktuell drei Dateien (+2 aus der Ausnahmeliste).

repo_1$ ls
kapitel_1.bak kapitel_1.txt kapitel_1.~ kapitel_2.txt kapitel_3.txt

Was passiert nun, wenn wir zurück zu main wechseln? Wie wird der Ordner danach aussehen? Versuchen Sie es aus.

repo_1$ git checkout main
Switched to branch 'main'
repo_1$ ls
kapitel_1.bak kapitel_1.txt kapitel_1.~ kapitel_3.txt

Sie haben wahrscheinlich erwartet, dass sowohl kapitel_2.txt als auch kapitel_3.txt nicht mehr da sind, da diese ja nicht in main erstellt wurden. Tatsächlich ist nur die Datei kapitel_2.txt nicht mehr da.

Das ist sehr einfach zu erklären. Git kümmert sich nur um Dateien, die unter seiner Kontrolle stehen (versioniert sind). Alle anderen Dateien werden einfach ignoriert. Genau das passiert mit kapitel_3.txt. Diese Datei steht noch nicht unter Versionskontrolle, weshalb diese von git unangetastet bleibt. Bei kapitel_2.txt ist der Fall anders. Diese steht unter Versionskontrolle. Damit weiß git, dass diese zwar im Zweig develop vorhanden ist, aber nicht in main. Aus diesem grund wird diese beim Wechsel gelöscht (oder angelegt beim Wechsel zurück).

Hinweis

Nicht versionierte Dateien sind für git unsichtbar und werden von diesem nicht angefasst.

Paralleles Arbeiten

Nun simulieren wir, dass auf beiden Branches nun gearbeitet wurde. Dazu versionieren wir die Datei kapitel_3.txt und fügen ein wenig Text hinzu.

# Kapitel 3
Nach zwei Monaten in der Versenkung ...

Das wird unsere Basis für den nächsten Kapitel, in dem wir versuchen die Branches zusammenzuführen. Am Ende sollte die Versionshistorie in etwa wie folgt aussehen:

repo_1$ git pl
* 663ea5a (HEAD -> main) Versenkung
* 63bb3f0 Kapitel 3 Plot
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

↩︎
↩︎

Änderungen eines Zweiges in ein Anderes übernehmen

Mon, 01 Jan 0001 00:00:00 +0000

Nach getaner Arbeit sollen die unterschiedlichen Stände der Arbeit wieder zusammengeführt werden. Dabei kann es zu 3 Konstellationen kommen:

Fast-Merge: Es wurden nur Änderungen auf neuen Branch gemacht, aber nicht auf main. Damit kann git einfach den Zeiger für main Branch auf den neuen Stand setzen. In diesem Fall spricht man von “Fast Merge”. Es wird dabei kein extra Commit erzeugt.
Merge: Beim Zusammenführen sind keine Probleme augetreten. In diesem Fall wir ein sogenannter “Merge”-Commit erstellt. Im Gegensatz zu einem normalen Commit, hat dieser Informationen zu den beiden Branches, statt nur einen.
Conflict: Beim Zusammenführen kommt es zu einem Konflikt, den git nicht selbst lösen kann. Wir müssen alle Konflikte beseitigen und das Zusammenführen abzuschließen.

Wir werden hier alle 3 Möglichkeiten durchspielen.

Fast Merge¹

Wechseln Sie zuerst auf den main-Branch, wenn noch nicht geschehen. Erstellen Sie einen neuen Branch feat_kap_4 und wechseln Sie zu diesem.

Hinweis

Da man meistens beim Erzeugen eines neuen Branches auch gleich zu diesem wechseln möchte, gibt es eine Abkürzung. Statt git branch <neuer_branch_name> und git checkout <neuer_branch_name> eingeben zu müssen, kann man auch kürzer den -b Flag nutzen: git checkout -b <neuer_branch_name> eingeben.

repo_1$ git checkout main
Already on 'main'
repo_1$ git checkout -b feat_kap_4
Switched to a new branch 'feat_kap_4'

Nun legen wir eine neue Datei an, mit Inhalt, den wir auch mehrere Commits verteilen.

# Kapitel 4
Im vierten Jahr stand der Weizen ...

Darauf folgte eine dreijährige Düre...

Am Ende sollte die Historie wie folgt aussehen:

repo_1$ git pl
* 10eabc1 (HEAD -> feat_kap_4) Die Düre-Jahre
* 054db53 Vierter Kapitel über...
* 663ea5a (main) Versenkung
* 63bb3f0 Kapitel 3 plot
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Wenn man den Pfad folgt, sieht man hier sehr gut, dass main eigentlich auf demselben Pfad liegt, wie unser neuer Branch feat_kap_4. Das ist die Voraussetzung für einen “Fast-Merge”.

Wechseln wir nun zurück zu main. Anschließen führen wir die Beiden Zweige zusammen. Dazu muss man immer auf dem Branch drauf sein, in dem man den anderen Zweig integrieren will. Die Integration wird mit git merge <branch_name> durchgeführt. In der Ausgabe sollte nun sichtbar sein, dass ein “Fast-Merge” durchgeführt wurde.

repo_1$ git checkout main
Switched to branch 'main'
repo_1$ git merge feat_kap_4
Updating 663ea5a..10eabc1
Fast-forward
 kapitel_4.txt | 4 ++++
 1 file changed, 4 insertions(+)
 create mode 100644 kapitel_4.txt

Auch an dem Log ist es sichtbar, dass ein “Fast-Merge” erstellt wurde:

Es sind genauso viele Commits da, wie vorher.
Letzter Commit hat denselben Hash. D.h. dieser wurde nicht geändert.
Beide Branches, main und feat_kap_4 zeigen auf denselben Commit.

repo_1$ git pl
* 10eabc1 (HEAD -> main, feat_kap_4) Die Düre-Jahre
* 054db53 Vierter Kapitel über...
* 663ea5a Versenkung
* 63bb3f0 Kapitel 3 plot
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Da die Zusammenführung erfolgreich war, können wir den nicht mehr benötigten Branch feat_kap_4 mit git branch -d <branch_name> löschen.

repo_1$ git branch -d feat_kap_4
Deleted branch feat_kap_4 (was 10eabc1).

Merge²

Für eine “normale” Zusammenführung haben wir auch bereits alles vorbereitet. Wir haben zwei Branches, auf denen parallel gearbeitet wurde, main und develop. Nun können wir wieder auf main wechsel, falls noch nicht der Fall ist, und develop integrieren.

repo_1$ git checkout main
Already on 'main'
repo_1$ git merge develop
Merge made by the 'ort' strategy.
 kapitel_2.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 kapitel_2.txt
repo_1$ git pl
* e779542 (HEAD -> main) Merge branch 'develop'
|\
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
* | 10eabc1 Die Düre-Jahre
* | 054db53 Vierter Kapitel über...
* | 663ea5a Versenkung
* | 63bb3f0 Kapitel 3 plot
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

An dem Log können wir sehr gut sehen, dass es dieses Mal ein neuer Commit (e779542) erzeugt wurde, der mit zwei anderen Commits (aac4d8b und 10eabc1) verbunden ist.

↩︎
↩︎

Konflikte beim Zusammenführen lösen

Mon, 01 Jan 0001 00:00:00 +0000

Erstellen wir für einen Konflikt zuerst einen neuen Branch.

repo_1$ git checkout -b feat_kap_5
Switched to a new branch 'feat_kap_5'

Erstellen Sie nun eine neue Datei kapitel_5.txt mit dem folgenden Inhalt und fügen Sie diese Datei zur Versionsverwaltung.

# Kapitel 5
Nach 8 stünddiger Fahrt ...

_repo_1> git commit -m "Fahrt im Zug"
[feat_kap_5 1b28574] Fahrt im Zug
 1 file changed, 2 insertions(+)
 create mode 100644 kapitel_5.txt

Jetzt ändern wir bereits vorhandene Dateien, um einige Konflikte zu provozieren. Ändern Sie die Datei kapitel_1.txt wie folgt (+-neuer Inhalt, --gelöschter Inhalt).

Es war ein Mal...
- Nach 20 Jahren treffen sich die Freunde wieder.
+ Nach langen 19 Jahren trafen sich die Freunde wieder,
+ um neue Pläne zu schmieden.
Sie verabredeten sich in ihrem alten Kaffee zu treffen,

Ändern Sie noch die Datei kapitel_4.txt wie folgt.

Im vierten Jahr stand der Weizen ...

- Darauf folgte eine dreijährige Düre...
+ Nach 3 Jahren der sehr guten Ernten kam nun die Dürre,
+ die die nächsten 8 Jahre andauern sollte.

Das Log sollte in etwa wie unten aussehen.

repo_1$ git pl
* 408a803 (HEAD -> feat_kap_5) Kapitel 4 überarbeitet
* 47c1c6d Kapitel 1 überarbeitet
* 1b28574 Fahrt im Zug
* e779542 (main) Merge branch 'develop'
|\
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
* | 10eabc1 Die Düre-Jahre
* | 054db53 Vierter Kapitel über...
* | 663ea5a Versenkung
* | 63bb3f0 Kapitel 3 plot
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Wechseln wir nun auf den main Branch und machen mit den Änderungen weiter.

repo_1$ git checkout main
Switched to branch 'main'

Auch hier ändern wird die beiden Dateien kapitel_1.txt und kapitel_4.txt an denselben Zeilen. Zusätzlich legen wir auch einen neuen Kapitel 6 an.

- Nach 20 Jahren treffen sich die Freunde wieder.
+ Nach nicht ganz 20 Jahren treffen sich die Freunde wieder.

- Darauf folgte eine dreijährige Düre...
+ Darauf folgte eine achtjährige Dürre...

Vor dem Zusammenführena sollte das Log nun wie folgt aussehen.

repo_1$ git pl
* 618450e (HEAD -> main) Kapitel 6 gestartet
* 54a8d9a Kapitel 4 überarbeitet
* 0b1ad44 Kapitel 1 ausgearbeitet
| * 408a803 (feat_kap_5) Kapitel 4 überarbeitet
| * 47c1c6d Kapitel 1 überarbeitet
| * 1b28574 Fahrt im Zug
|/
* e779542 Merge branch 'develop'
|\
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
* | 10eabc1 Die Düre-Jahre
* | 054db53 Vierter Kapitel über...
* | 663ea5a Versenkung
* | 63bb3f0 Kapitel 3 plot
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

Versuchen Sie nun die Zusammenführung. Diese sollte nun scheitern, da git nicht in der Lage ist, die Konflikte zu lösen. Die Änderungen sind auf beiden Branches in denselben Zeilen. Wir müssen die Konflikte manuell lösen.

repo_1$ git merge feat_kap_5
Auto-merging kapitel_1.txt
CONFLICT (content): Merge conflict in kapitel_1.txt
Auto-merging kapitel_4.txt
CONFLICT (content): Merge conflict in kapitel_4.txt
Automatic merge failed; fix conflicts and then commit the result.

Übernahme einer der Versionen¹

Der main Brnach befindet sich wegen dem Konflikt nun in einem “Merge” Status. Mit git status können wir immer den aktuellen Stand bei Konfliktlösung sehen.

repo_1$ git status
On branch main
You have unmerged paths.
 (fix conflicts and run "git commit")
 (use "git merge --abort" to abort the merge)

Changes to be committed:
 new file: kapitel_5.txt

Unmerged paths:
 (use "git add <file>..." to mark resolution)
 both modified: kapitel_1.txt
 both modified: kapitel_4.txt

Bei dem Konflikt im Kapitel 1 möchten wir einfach die Änderungen aus dem Branch feat_kap_4 übernehmen. Dazu nutzen wir den checkout Befehl mit dem --theirs oder --ours Parameter und dem Dateinamen.

--theirs: Es wird die Version aus dem anderen Branch genommen. Da wir auf main sind, ist es die Version aus Branch feat_kap_5.
--ours: Es wird unsere Version genommen, also aus dem main Branch.

Nach dem Auschecken der gewollten Version muss die Lösung des Konfliktes mit git add, beendet werden.

repo_1$ git checkout --theirs -- kapitel_1.txt
repo_1$ git add kapitel_1.txt
repo_1$ git status
On branch main
You have unmerged paths.
 (fix conflicts and run "git commit")
 (use "git merge --abort" to abort the merge)

Changes to be committed:
 modified: kapitel_1.txt
 new file: kapitel_5.txt

Unmerged paths:
 (use "git add <file>..." to mark resolution)
 both modified: kapitel_4.txt

Manuelle Korrekturen

Nun haben wir noch ein Konflikt, in der Datei kapitel_4.txt. Diesen Konflikt möchten wir manuell lösen, da wir Änderungen aus beiden Branches kombinieren möchten. Aktuell sieht die Datei wie folgt aus:

# Kapitel 4
Im vierten Jahr stand der Weizen ...

<<<<<<< HEAD
Darauf folgte eine achtjährige Düre...
=======
Nach 3 Jahren der sehr guten Ernten, kam nun die Dürre,
die die nächsten 8 Jahre andauern sollte.
>>>>>>> feat_kap_5

<<<<<<< HEAD: Markierung für den Start des Bereiches mit den Änderungen aus dem aktuellen Branch.
=======: Markierung zur Trennung zwischen den Änderungen aus den beiden Brnaches.
>>>>>>> feat_kap_5: Markierung zum Ende der Änderungen aus dem anderen Branch.

Die Datei können wir nun manuell bearbeiten und in den Zustand bringen, den wir haben möchten. Die Markierungen sollen am Ende alle entfernt werden.

# Kapitel 4
Im vierten Jahr stand der Weizen ...

Darauf folgte eine achtjährige Dürre...
Die die nächsten 8 Jahre andauern sollte.

Auch die Lösung von diesem Konflikt muss mit git add beendet werden. Der gesammte Merge wird dann über ein git commit abgeschlossen.

repo_1$ git add kapitel_4.txt
repo_1$ git status
On branch main
All conflicts fixed but you are still merging.
 (use "git commit" to conclude merge)

Changes to be committed:
 modified: kapitel_1.txt
 modified: kapitel_4.txt
 new file: kapitel_5.txt
repo_1$ git commit -m "Merge branch 'feat_kap_5'"
[main 7a000b4] Merge branch 'feat_kap_5'

Die Historie sollte nun unsere erfolgreiche Zusammenführung anzeigen.

repo_1$ git pl
* 7a000b4 (HEAD -> main) Merge branch 'feat_kap_5'
|\
| * 408a803 (feat_kap_5) Kapitel 4 überarbeitet
| * 47c1c6d Kapitel 1 überarbeitet
| * 1b28574 Fahrt im Zug
* | 618450e Kapitel 6 gestartet
* | 54a8d9a Kapitel 4 überarbeitet
* | 0b1ad44 Kapitel 1 ausgearbeitet
|/
* e779542 Merge branch 'develop'
|\
| * aac4d8b (develop) Nachtszene
| * e6b896a Ideen zum zweiten Kapitel
* | 10eabc1 Die Düre-Jahre
* | 054db53 Vierter Kapitel über...
* | 663ea5a Versenkung
* | 63bb3f0 Kapitel 3 plot
|/
* 027c2f3 Korrekturen am Kapitel 1
* e4c2672 Treffen nach 20 Jahren
* bd4b2df Fortsetzung in vielen Jahren
* e47bbe0 Kapitel 1 der Geschichte starten
* c3b4e8b Add repo ignore file for temp files
* e12fb6d feat: Start des ersten Kapitels

↩︎

Rebase: Verzweigung auf neue Basis setzen

Mon, 01 Jan 0001 00:00:00 +0000

Als Alternative für ein merge, kann auch ein rebase¹ gemacht werden. Die Unterschiede schauen wir uns jetzt an.

Was ist ein `rebase`?

Git Rebase ist eine Methode, um die Commit-Historie zu verändern und zu bereinigen. Im Gegensatz zu git merge, der zwei Branches zusammenführt und einen neuen Merge-Commit erstellt, sortiert git rebase die Commits neu und wendet sie in linearer Folge an, was eine sauberere Projekthistorie erzeugt.

Ablauf bei einem `rebase`

Bei einem Rebase nimmt Git alle Commits aus deinem aktuellen Branch (z.B. feature-branch) und wendet sie erneut auf einen anderen Branch (z.B. main) an. Dies geschieht wie folgt:

Git identifiziert den gemeinsamen Vorfahren-Commit beider Branches
Git speichert temporäre Kopien der Änderungen jedes Commits im Feature-Branch
Der Feature-Branch wird auf den Ziel-Branch (main) zurückgesetzt
Die gespeicherten Änderungen werden einzeln als neue Commits auf den Ziel-Branch angewendet (die Historie ändert sich damit)

Graph für git merge

Git Graph vor dem Rebase

Git Graph nach dem Rebase

Einen `rebase` durchführen

Um en rebase zu erstellen, sollten wir vorher Änderungen auf zwei Verzweigungen erstellen, so dass ein merge nicht mehr durch ein “fast forward” durchgeführt werden kann.

Erstellen wir für Rebase zuerst einen neuen Branch.

repo_1$ git checkout -b feat_kap_7
Switched to a new branch 'feat_kap_7'

Erstellen Sie nun eine neue Daten kapitel_7.txt mit folgenden Inhalt und fügen Sie diese Datei zur Versionsverwaltung hinzu.

Fügen Sie folgenden Inhalt der Datei hinzu und schreiben Sie die Version fest.

# Kapitel 7
Der Ausgang der Geschichte wird angepasst ...

Wechseln Sie nun zurück zu dem main Branch, um auch hier einige Änderungen vorzunehmen.

repo_1$ git checkout main
Switched to branch 'main'

Machen Sie nun folgende Änderungen in der Datei kapitel_6.txt.

# Kapitel 6
Und es wurde endlich besser...

Die Historie sieht nun wie folgt aus (gekürzt):

repo_1$ git pl
* cf10f7f (HEAD -> main) Besser
| * 67f77fa (feat_kap_7) Neue Geschichte
| * 9a14335 Start mit Kapitel 7
|/
* 4a8d01e Merge branch 'feat_kap_5'
|\ 
| * 654fae0 Kapitel 4 überarbeitet
| * a7d8ad7 Kapitel 1 überarbeitet
| * 602f965 Fahrt im Zug
* | a915c82 Kapitel 6 gestartet
* | 4893d66 Kapitel 4 überarbeitet
* | 401162d Kapitel 1 ausgearbeitet
|/
* ae2918a Merge branch 'develop'

An den Graphen sehen wir, dass hier ein Merge zu keinem “Fast Merge” führen würde (keine lineare Historie), sondern einen “Merge”-Commit (wie bei der Zusammenführung des feat_kap_5 Branches). Das können wir nun mit einen Rebase verhindern. Wechseln Sie zuerst auf den feat_kap_7 branch. Dieser soll nun neue “Basis” bekommen.

repo_1$ git checkout feat_kap_7
Switched to branch 'feat_kap_7'

Nun führen wir ein Rebase auf diesem Branch durch. D.h. der Branch bekommt eine neue Basis. Aktuell liegt diese auf dem Commit Merge branch 'feat_kap_5'.

git rebase main
Successfully rebased and updated refs/heads/feat_kap_7.

In dem Graphen sehen wir nun, dass die Basis sich von Merge branch 'feat_kap_5' zu Besser verschoben hat.

repo_1$ git pl
* 874e90c (HEAD -> feat_kap_7) Neue Geschichte
* 71c03a0 Start mit Kapitel 7
* cf10f7f (main) Besser
* 4a8d01e (origin/main) Merge branch 'feat_kap_5'
|\ 
| * 654fae0 Kapitel 4 überarbeitet
| * a7d8ad7 Kapitel 1 überarbeitet
| * 602f965 Fahrt im Zug
* | a915c82 Kapitel 6 gestartet
* | 4893d66 Kapitel 4 überarbeitet
* | 401162d Kapitel 1 ausgearbeitet
|/
* ae2918a Merge branch 'develop'

Mit diesen Graphen können wir den Branch feat_kap_7 relativ einfach über einen “Fast Merge” in unser main Branch integrieren.

repo_1$ git checkout main
Switched to branch 'main'
repo_1$ git merge feat_kap_7
Updating cf10f7f..874e90c
Fast-forward
 kapitel_7.txt | 2 ++
 1 file changed, 2 insertions(+)
 create mode 100644 kapitel_7.txt
repo_1$ git branch -d feat_kap_7
Deleted branch feat_kap_7 (was 874e90c).

Konflikte beim `rebase` lösen

Genau wie beim merge kann es auch bei rebase zu Konflikten führen, die gelöst werden müssen. Im Gegensatz zu merge können die Konflikte mehrmals vorkommen, praktisch bei jeder “Wiedergabe” (replay) eines Commits auf die neue Basis. Dabei stoppt das Rebase und erlaubt uns die Konflikte zu lösen (ähnlich wie bei merge).

Mit git add markieren wir eine Datei mit dem Konflikt, dass der Konflikt beseitigt ist.
Mit git rebase --continue setzen wir das Rebase fort (wiedergeben den nächsten Commit auf die neue Basis).
Mit git rebase --abort können wir das Rebase abbrechen (ähnlich wie beim merge während eines Konfliktes).

Warnung

Da ein rebase die Historie verändert, sollte dieser nur auf den Commits durchgeführt werden, die noch nicht zu einem Zentralen git-Server synchronisiert wurden (oder nur auf Branches auf denen man allein arbeitet).

↩︎

Squash: Commits zusammenführen

Mon, 01 Jan 0001 00:00:00 +0000

Was ist `squash`¹?

Ein Git Squash ermöglicht es, mehrere Commits zu einem einzelnen Commit zusammenzufassen. Dies ist besonders nützlich, um die Commit-Historie sauber zu halten. Dabei kan man squash sowohl mit rebase (aktueller Branch) als auch mit merge nutzen.

Anwendung mit `rebase`

Ein rebase kann in einen interaktiven Modus durchgeführt werden (Parameter -i oder --interactive). Dabei werden alle betroffenen Commits, die “wiedergegeben” werden, in dem Texteditor angezeigt und können angepasst werden.

Für squash mit rebase geben wir die Anzahl der Commits, die zusammengefasst werden sollen mit HEAD-<n> an (die selbe Syntax, die wir bereits mit diff gesehen haben, um Commits relativ anzusprechen). Wir wollen nun die letzten Beiden Commits unserer Historie zusammenfassen.

repo_1$ git pl
* 874e90c (HEAD -> main) Neue Geschichte
* 71c03a0 Start mit Kapitel 7
* cf10f7f Besser
* 4a8d01e (origin/main) Merge branch 'feat_kap_5'
...

Dazu führen wir das interaktive rebase für die letzten 2 Commits durch.

repo_1$ git rebase -i HEAD~2

Darauf erscheint im Texteditor die Auflistung der betroffenen Commits (und ein Wenig Dokumentation dazu - mit # auskommentiert):

pick 71c03a0 Start mit Kapitel 7
pick 874e90c Neue Geschichte

# Rebase cf10f7f..874e90c onto cf10f7f (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
# commit's log message, unless -C is used, in which case
# keep only this commit's message; -c is same as -C but
# opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# create a merge commit using the original merge commit's
# message (or the oneline, if no original merge commit was
# specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
# to this position in the new commits. The <ref> is

Relevant sind nur die ersten beiden Zeilen. Jede Zeile (Commit), die mit pick beginnt, wird im Original übernommen - wird also wieder zu einem Commit. Ändern Sie die Commits, die Zusammengefasst werden sollen von pick zu squash (in unserem Beispiel also den zweiten Commit).

pick 71c03a0 Start mit Kapitel 7
squash 874e90c Neue Geschichte

Unter Linux/macOS können Sie den “vi(m)"-Editor mit Esc-Taste und dann mit :wq (write and quit) verlassen.

Nun können Sie auch das finale Commit bearbeiten, wenn Sie es möchten:

# This is a combination of 2 commits.
# This is the 1st commit message:

Start mit Kapitel 7

# This is the commit message #2:

Neue Geschichte

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Mon Apr 7 08:01:30 2025 +0200
#
# interactive rebase in progress; onto cf10f7f
# Last commands done (2 commands done):
# pick 71c03a0 Start mit Kapitel 7
# squash 874e90c Neue Geschichte
# No commands remaining.
# You are currently rebasing branch 'main' on 'cf10f7f'.
#
# Changes to be committed:
# new file: kapitel_7.txt
#

Mit dem Verlassen des Commit-Message Editors, wird die Historie umgeschrieben.

repo_1$ git rebase -i HEAD~2
[detached HEAD a93f4f8] Start mit Kapitel 7
 Date: Mon Apr 7 08:01:30 2025 +0200
 1 file changed, 2 insertions(+)
 create mode 100644 kapitel_7.txt
Successfully rebased and updated refs/heads/main.
repo_1$ git pl
* a93f4f8 (HEAD -> main) Start mit Kapitel 7
* cf10f7f Besser
* 4a8d01e (origin/main) Merge branch 'feat_kap_5'

Letzten Commit anpassen

Sollten nur die letzten Änderungen (bereits mit git add in das Staging-Bereich hinzugefügt, aber noch kein Commit erstellt) in das letzte Commit reinfließen, geht es noch ein wenig einfacher. Dazu kann das --amend² Parameter vom commit-Command genutzt werden.

Machen Sie folgende Änderung in kapitel_7.txt.

# Kapitel 7
Der Ausgang der Geschichte wird angepasst ...
Und manchmal zusammengeführt...

Fügen Sie die Änderung zum Staging Bereich mit git add.

repo_1$ git add kapitel_7.txt

Nun können wir mit --amend diese Änderung zum letzten Commit hinzufügen. Wenn wir die Message des letzten Commits nicht ändern wollen, können wird den Parameter --no-edit anhängen, oder mit -m eine neue Message angeben.

repo_1$ git commit --amend -m "Kapitel 7 fängt an"
[main 28087f7] Kapitel 7 fängt an
 Date: Mon Apr 7 08:01:30 2025 +0200
 1 file changed, 3 insertions(+)
 create mode 100644 kapitel_7.txt

Mit dem Status sehen wir nun, dass keine Änderungen mehr vorliegen und and der Historie den geänderten letzten Commit (anderer Hash-Wert und Message).

repo_1$ git status
On branch main
Your branch is ahead of 'origin/main' by 2 commits.
 (use "git push" to publish your local commits)

nothing to commit, working tree clean
repo_1$ git pl
* 28087f7 (HEAD -> main) Kapitel 7 fängt an
* cf10f7f Besser
* 4a8d01e (origin/main) Merge branch 'feat_kap_5'
...

Warnung

Da sowohl rebase -i als auch commit --amend die Historie verändert, sollte dieser nur auf den Commits durchgeführt werden, die noch nicht zu einem Zentralen git-Server synchronisiert wurden (oder nur auf Branches auf denen man allein arbeitet).

↩︎
↩︎

Benannte Versionen mit Tags

Mon, 01 Jan 0001 00:00:00 +0000

Wir Menschen sind nicht dazu geeignet Hash-Werte zu merken. Das ist aber manchmal notwendig, um zu einem bestimmten Stand in der Geschichte zurückkehren zu können. Hier helfen und sogenannte Tags, die an ein Commit angehängt werden können. Wir können diese als eine kleine Notiz an einem Commit vorstellen.

Git unterstützt dabei zwei Arten von Tags.

Leichtgewichtige Tags, die nur aus dem Tag selbst bestehen. Es ist am Ende ein einfacher Zeiger auf den Commit, wie bei Branches, der sich aber nicht bewegt.
Annotierte Tags, die neben dem Tag selbst noch weitere Informationen tragen, wie eine zusätzliche Nachricht.

Leichtgewichtiger Tag

Legen wir zuerst einen leichtgewichtigen Tag an, der auf den letzten Commit zeigt. Dazu nutzen wir das git tag Befehl mit dem Namen des Tags.

repo_1$ git tag 'kap-05'
repo_1$ git pl
* 7a000b4 (HEAD -> main, tag: kap-05) Merge branch 'feat_kap_5'
|\
| * 408a803 (feat_kap_5) Kapitel 4 überarbeitet
...
repo_1$ git tag
kap-05

Mit git tag können wir alle Tags der Repositories auflisten lassen. Mit git show können wir die Informationen zu einem Commit, oder Tag aufrufen. Bei leichtgewichtigen erscheinen dabei keine zusätzlichen Informationen.

repo_1$ git show kap-05
commit 7a000b46cdd307aea91cc0e151fa6b7ff7daad78 (HEAD -> main, tag: kap-05)
Merge: 618450e 408a803
Author: Eugen [WebDucer] Richter <github@webducer.de>
Date: Mon May 2 06:56:58 2022 +0200

 Merge branch 'feat_kap_5'

diff --cc kapitel_4.txt
...

Annotierter Tag

Nun legen wir einen annotierten Tag an, der neben der Nachricht, auch auf einen bestimmten Commit angehängt wird, nicht den aktuellen. Dazu wird der Parameter -a (für annotiert) und -m (für Message) genutzt. Der Commit auf den wir uns beziehen, wird als Hash (oder HEAD-Relative-Referenz, wie bei diff) mit angegeben.

repo_1$ git tag -a 'kap-04' e779542 -m "Kapitel 4 über Tag"
repo_1$ git pl
* 7a000b4 (HEAD -> main, tag: kap-05) Merge branch 'feat_kap_5'
|\
| * 408a803 (feat_kap_5) Kapitel 4 überarbeitet
| * 47c1c6d Kapitel 1 überarbeitet
| * 1b28574 Fahrt im Zug
* | 618450e Kapitel 6 gestartet
* | 54a8d9a Kapitel 2 überarbeitet
* | 0b1ad44 Kapitel 1 ausgearbeitet
|/
* e779542 (tag: kap-04) Merge branch 'develop'
...
_repo_1$ git show kap-04
tag kap-04
Tagger: Eugen [WebDucer] Richter <github@webducer.de>
Date: Mon May 2 07:13:57 2022 +0200

Kapitel 4 über Tag

commit e7795427bf9235f54e8fc3cc73b0fa4f43678373 (tag: kap-04)
Merge: 10eabc1 aac4d8b
Author: Eugen [WebDucer] Richter <github@webducer.de>
Date: Mon May 2 05:46:44 2022 +0200
...

Bei git show sehen wir nun neben den Informationen zu dem Commit selbst (fängt mit commit e7794 an) auch die Informationen zu dem Tag (es können auch mehrere sein) oberhalb von diesem. Hier werden neben der Nachricht auch die Informationen zu dem Ersteller des Tags angezeigt.

Links

Mon, 01 Jan 0001 00:00:00 +0000

Allgemein

Bücher

Blogs / Tutorials

Software (git Clients)

Hinweis

Die meisten heutigen IDEs und Editoren verfügen über direkte Integration mit einer Versionsverwaltung, vor allem auch mit git.

Visual Studio Code
Android Studio
JetBrains InteliJ, Rider, PyCharm und weitere
Visuals Studio
XCode
und viele weitere

Git Hoster

Alle Hoster bieten ein kostenkoses Konto an. Mit diesem ist es meistens möglich mit bis zu 5 Mitstreitern kostenlos zusammenzuarbeiten und unbegrenzte Anzahl an privaten Repositories zu haben. Viele bieten auch ein kostenloses Zeitkontingent für die integrierte CI/CD Pipeline.

Git - Versionsverwaltung für Dokumente, Dokumentationen, Code und mehr

Tue, 02 Jun 2026 07:00:00 +0100

Arbeiten Sie in einer Gruppe an einem Dokument oder programmieren Sie gerne? Wollen Sie wissen, was Sie oder Andere zuletzt am Dokument geändert haben?

Erfahren Sie mehr dazu

Lernen Sie, wie eine Version (von einem oder mehreren Dokumenten) mit Git auf dem Rechner gesichert, verglichen, mit anderen geteilt, zusammengeführt und wiederhergestellt werden kann. Erstellen Sie mehrere Bearbeitungszweige, um an mehreren Dokumentversionen parallel arbeiten zu können.

Kursinhalt: Grundlagen Versionierung; Geschichte; aktuelle Systeme; Strategien; lokaler Einsatz von Git; Git mit Server-Einsatz; Arbeiten an mehreren Zweigen.

Nächster Termin an der MVHS

2x, 18.11.2026 - 25.11.2026
1. Mi. 18.11.2026, 18:00 – 21:00 Uhr
2. Mi. 25.11.2026, 18:00 – 21:00 Uhr

Workshop: Versionen dezentral verwalten mit Git

Mon, 19 Jan 2026 00:00:00 +0000

Hinweis

Die Code-Beispiele werden für Linux/macOS in Bash und unter Windows in PowerShell (Core) abgebildet. Sind die erforderlichen Befehle gleich, werden diese nur in Bash angezeigt. Die Anweisungen können 1:1 in PowerShell eingegeben werden.

Arbeiten Sie in einer Gruppe an einem Dokument oder programmieren Sie gerne? Wollen Sie wissen, was Sie oder Andere zuletzt am Dokument geändert haben?

Installation von Git

Git |

Installation von Git

Initialisierung eines lokalen Repositorys

Ordner anlegen

Repository initialisieren

Prüfen des aktuellen Zustandes von Repository

Eine Datei versionieren

Datei zum Staging-Bereich hinzufügen

Änderungen festschreiben

Benutzer in git einrichten

Allgemeiner Ablauf

Historie anzeigen lassen

Verkürzte Anzeige der Historie

Aliases

Ausnahmen für Versionierung

Globale Ausnahmen (Betriebssystem)

Ausnahmen im Repository

Änderungen zwischen Version anzeigen

Aktuelle Änderungen zeigen

Unterschiede zwischen zwei Commits

HEAD Anker für diff nutzen

Reihenfolge ist wichtig

Verzweigungen (Branches) anlegen

Branches anzeigen

Branches anlegen

Zum Branch wechseln

Branch Verhalten

Paralleles Arbeiten

Änderungen eines Zweiges in ein Anderes übernehmen

Fast Merge1

Merge2

Konflikte beim Zusammenführen lösen

Übernahme einer der Versionen1

Manuelle Korrekturen

Rebase: Verzweigung auf neue Basis setzen

Was ist ein rebase?

Ablauf bei einem rebase

Einen rebase durchführen

Konflikte beim rebase lösen

Squash: Commits zusammenführen

Was ist squash1?

Anwendung mit rebase

Letzten Commit anpassen

Benannte Versionen mit Tags

Leichtgewichtiger Tag

Annotierter Tag

Links

Allgemein

Bücher

Blogs / Tutorials

Software (git Clients)

Git Hoster

Git - Versionsverwaltung für Dokumente, Dokumentationen, Code und mehr

Erfahren Sie mehr dazu

Nächster Termin an der MVHS

Workshop: Versionen dezentral verwalten mit Git

`HEAD` Anker für `diff` nutzen

Fast Merge¹

Merge²

Übernahme einer der Versionen¹

Was ist ein `rebase`?

Ablauf bei einem `rebase`

Einen `rebase` durchführen

Konflikte beim `rebase` lösen

Was ist `squash`¹?

Anwendung mit `rebase`