Verzweigungen (Branches) anlegen
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.
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>1 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 checkout2 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.txtan - 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.txtan, 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).
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