Git-Branching: Grundlegende Operationen

Einführung

Willkommen zurück, Zeitreisender! Heute werden wir deine Fähigkeiten in der Zeitreise auf die nächste Stufe heben – mit Git-Branches!

Stell dir vor, du könntest alternative Universen für dein Projekt erschaffen, in denen du mit verrückten Ideen experimentieren kannst, ohne deine Haupt-Zeitlinie zu gefährden. Genau das ermöglichen dir Git-Branches! Sie sind wie Paralleldimensionen für deinen Code, in denen du neue Funktionen entwickeln, Fehler beheben oder gewagte Experimente wagen kannst, ohne Angst vor Fehlern haben zu müssen.

Am Ende dieses Praktikums wirst du ein Meister des Multiversums sein. Du wirst in der Lage sein, neue Realitäten (Branches) zu erschaffen, zwischen ihnen hin- und herzuspringen (Checkout oder Switch), sie zu kombinieren (Merge) und sogar Universen zu löschen, die du nicht mehr benötigst. Diese Superkräfte sind für jeden zeitreisenden Entwickler unerlässlich, egal ob du alleine arbeitest oder Teil eines Teams von dimensionsspringenden Codern bist.

Bist du bereit, ein Git-Branch-Zauberer zu werden? Dann legen wir los!

Einrichten deines multiversalen Hubs

Zuerst müssen wir einen zentralen Hub für all unsere alternativen Realitäten einrichten. Dies wird unser Haupt-Git-Repository sein.

1. Öffne dein Terminal. Dies ist deine Steuerkonsole, um zwischen den Dimensionen zu springen.

2. Navigiere zu deinem Projektverzeichnis:

cd ~/project

Dieser Befehl wechselt dein aktuelles Verzeichnis in den Ordner "project" in deinem Home-Verzeichnis. Wenn du dir jemals unsicher bist, wo du dich befindest, kannst du den Befehl pwd verwenden, um dein aktuelles Arbeitsverzeichnis anzuzeigen. Das ist ein nützlicher Trick, falls du dich im Terminal einmal verlaufen solltest.

3. Erstellen wir einen neuen Ordner für unsere multiversalen Experimente:

mkdir git-branch-lab
cd git-branch-lab

Der Befehl mkdir erstellt ein neues Verzeichnis, und mit cd wechseln wir hinein. So haben wir eine saubere Arbeitsumgebung. Betrachte diesen neuen Ordner als den Kontrollraum deiner Zeitreise-Operation.

4. Jetzt initialisieren wir unseren Hub (das Git-Repository):

git init

Dieser Befehl erstellt ein neues Git-Repository im aktuellen Verzeichnis. Er legt alle notwendigen Dateien an, die Git benötigt, um dein Projekt zu verfolgen. Diese Dateien sind in einem versteckten Ordner namens .git gespeichert.

Du solltest eine Nachricht wie diese sehen:

Initialized empty Git repository in /home/labex/project/git-branch-lab/.git/

Herzlichen Glückwunsch! Du hast gerade einen Hub für unendliche Möglichkeiten erschaffen! Dies ist das Fundament, auf dem all deine Zeitreise-Abenteuer aufgebaut werden.

5. Erstellen wir eine Notiz für unser zukünftiges Ich, um zu erklären, was dieser Ort ist:

echo "## Git Branch Lab" > README.md
echo "This is my hub for multiversal Git branch experiments" >> README.md

Das bewirken diese Befehle:

• Der erste Befehl erstellt eine neue Datei namens README.md und schreibt "## Git Branch Lab" hinein. In Markdown erzeugt das Symbol '#' eine Überschrift. Diese Datei dient als Benutzerhandbuch für unseren Multiversum-Hub.
• Der zweite Befehl fügt eine weitere Zeile an die README.md an. Das Symbol '>>' bedeutet "am Ende der Datei hinzufügen". Wir ergänzen unser Benutzerhandbuch also um ein paar Details.

Wenn du neugierig bist, was du gerade erstellt hast, kannst du den Befehl cat README.md verwenden, um den Inhalt der Datei anzuzeigen. Das ist so, als würdest du das Handbuch deines Hubs lesen.

6. Erstellen wir nun unseren ersten Speicherpunkt (Commit) in diesem neuen Universum:

git add README.md
git commit -m "Initial commit: Create the multiverse hub"

Lass uns das aufschlüsseln:

• git add README.md weist Git an, Änderungen an der README.md zu verfolgen. Damit wird die Datei für den Commit vorgemerkt (Staging). Stell dir das Staging wie das Vorbereiten der Datei für die Reise vor.
• git commit erstellt einen neuen Commit (Speicherpunkt) mit den vorgemerkten Änderungen. Das ist wie eine Momentaufnahme unseres aktuellen Universums.
• Das Flag -m erlaubt es dir, direkt eine Commit-Nachricht einzugeben. Versuche immer, klare und beschreibende Nachrichten zu schreiben! Diese Nachricht ist wie eine Notiz, die erklärt, was wir in diesem Schnappschuss geändert haben.

Wenn du dir unsicher bist, was bereits vorgemerkt oder committet wurde, kannst du git status verwenden. Das ist wie ein Statuscheck deiner Zeitreise-Ausrüstung.

Erschaffen deiner ersten alternativen Realität

Nachdem wir unser Hauptuniversum (den Master-Branch) eingerichtet haben, erschaffen wir nun unsere erste alternative Realität!

1. Erstelle einen neuen Branch mit dem Namen feature-dimension:

git branch feature-dimension

Dieser Befehl erstellt einen neuen Branch, wechselt aber noch nicht dorthin. Stell es dir so vor, als würdest du ein neues Paralleluniversum erschaffen, während du selbst noch im ursprünglichen bleibst. Es ist wie ein Bauplan für eine neue Realität, die du aber noch nicht betreten hast.

Du hast eine neue Zeitlinie erschaffen, bist aber noch nicht in ihr. Schauen wir uns alle vorhandenen Zeitlinien an:

git branch

Du solltest Folgendes sehen:

  feature-dimension
* master

Das Sternchen * zeigt an, in welcher Realität du dich gerade befindest. Momentan bist du noch im Hauptuniversum (master). Der master-Branch ist der Standard-Branch, den Git beim Initialisieren eines Repositories automatisch erstellt.

Tipp: Drücke q, um die Branch-Liste zu verlassen und zum Terminal zurückzukehren.

2. Springen wir nun in unsere neue Realität:

git checkout feature-dimension

Dieser Befehl bewirkt zwei Dinge:

1. Er wechselt dein aktuelles Arbeitsverzeichnis zum Branch feature-dimension.
2. Er aktualisiert die Dateien in deinem Verzeichnis so, dass sie dem Zustand des feature-dimension-Branches entsprechen. Es ist, als würdest du durch ein Portal in die neue Realität treten.

Wenn du nun erneut git branch ausführst, siehst du:

* feature-dimension
  master

Das * ist gewandert und zeigt an, dass du erfolgreich in deine neue Dimension gesprungen bist! Du arbeitest jetzt in dieser alternativen Realität.

Alternativ kannst du git switch feature-dimension verwenden, um dasselbe Ergebnis zu erzielen. git switch ist ein neuerer Befehl (eingeführt in Git 2.23), der speziell für das Wechseln von Branches entwickelt wurde, was ihn klarer und intuitiver macht. Beide Befehle führen zum Ziel, aber git switch wird aufgrund seiner Eindeutigkeit oft bevorzugt.

Keine Sorge, wenn du noch keine Änderungen an deinen Dateien siehst. Wenn du einen neuen Branch erstellst, beginnt er als exakte Kopie des Branches, auf dem du dich gerade befunden hast. Der spannende Teil beginnt, wenn wir anfangen, Änderungen vorzunehmen! Diese initialen Kopien stellen sicher, dass jede Realität auf demselben Fundament startet.

Profi-Tipp: In neueren Git-Versionen kannst du einen neuen Branch erstellen und sofort dorthin wechseln – mit nur einem Befehl: git checkout -b feature-dimension oder git switch -c feature-dimension. Das ist so, als würdest du ein Portal erschaffen und im selben Moment hindurchtreten! Die Verwendung von -b bei git checkout oder -c bei git switch kombiniert das Erstellen und Wechseln in einem Schritt.

Falls du dich jemals verirrst und nicht mehr weißt, in welcher Dimension (Branch) du bist, führe einfach wieder git branch aus. Der Branch mit dem * ist dein aktueller Standort. Das ist wie ein Blick auf die Karte des Multiversums.

Deine neue Realität gestalten

Da wir uns nun in unserer neuen Dimension befinden, lassen uns Änderungen vornehmen, die nur hier existieren. Denk daran: Was auch immer wir hier tun, wird unser Hauptuniversum nicht beeinflussen, bis wir uns entscheiden, sie zusammenzuführen (mergen). Das erlaubt uns, sicher zu experimentieren, ohne die Haupt-Zeitlinie zu stören.

1. Erschaffen wir ein neues Artefakt in dieser Realität:

echo "This is a powerful artifact from another dimension" > dimensional-artifact.txt

Dieser Befehl erstellt eine neue Datei namens dimensional-artifact.txt und schreibt eine Nachricht hinein. Das Symbol > wird verwendet, um eine neue Datei zu erstellen (oder eine bestehende zu überschreiben). Dieses Artefakt ist einzigartig in unserer aktuellen Realität.

2. Nun bewahren wir dieses Artefakt in unserer Zeitlinie auf:

git add dimensional-artifact.txt
git commit -m "Create a powerful interdimensional artifact"

Diese Befehle sollten dir aus Schritt 1 bekannt vorkommen. Wir weisen Git an, unsere neue Datei zu verfolgen, und erstellen dann einen Speicherpunkt mit einer beschreibenden Nachricht. Das ist wie eine fotografische Dokumentation des neu entdeckten Artefakts.

3. Aktualisieren wir auch unsere Notiz für die Zukunft über diese neue Realität:

echo "##### Feature Dimension" >> README.md
echo "We've discovered a powerful artifact in this reality" >> README.md

Diese Befehle fügen neue Zeilen zu unserer README.md hinzu. Das Symbol >> hängt den Text an eine bestehende Datei an, anstatt sie zu überschreiben. Wir aktualisieren unser Handbuch, um unsere Entdeckungen in der neuen Dimension festzuhalten.

4. Speichern wir auch diese Änderungen:

git add README.md
git commit -m "Document the discovery of the artifact"

Wieder erstellen wir einen Speicherpunkt, diesmal für unsere aktualisierte README.md. Wir sichern die Dokumentation für unser zukünftiges Ich.

Gute Arbeit! Du hast nun Änderungen in deiner alternativen Realität vorgenommen. Diese Änderungen existieren vorerst nur im feature-dimension-Branch. Wenn du zum master-Branch zurückkehren würdest, wären diese Änderungen dort nicht sichtbar. Diese Trennung stellt sicher, dass Experimente in einer Realität keine Auswirkungen auf die anderen haben.

Um den Unterschied zwischen deinem aktuellen Branch und dem Master-Branch zu sehen, kannst du den Befehl git diff master verwenden. Dies zeigt dir alle Änderungen an, die du in deiner aktuellen Realität im Vergleich zur Haupt-Zeitlinie vorgenommen hast. Das ist wie ein Vergleich der Zustände zweier Universen.

Realitäten zusammenführen

Nachdem wir in unserer alternativen Realität erstaunliche Entdeckungen gemacht haben, ist es an der Zeit, diese zurück in unser Hauptuniversum zu bringen. Dieser Prozess wird "Merging" genannt.

1. Zuerst springen wir zurück in unsere Hauptrealität:

git checkout master

oder

git switch master

Beide Befehle bringen uns zurück zum master-Branch.

• git checkout ist der klassische Befehl zum Wechseln von Branches. Er existiert seit den Anfängen von Git und wird weiterhin unterstützt.
• git switch ist der modernere Befehl, der mit Git 2.23 eingeführt wurde. Er ist intuitiver gestaltet.

Du kannst beide verwenden, aber git switch ist aufgrund seiner Klarheit meist die bessere Wahl.

Wenn du dir jetzt deine Dateien ansiehst, wirst du feststellen, dass dein interdimensionales Artefakt verschwunden ist! Keine Sorge, es ist in der anderen Dimension sicher aufgehoben. Dies zeigt, dass Änderungen in einem Branch isoliert bleiben, bis sie zusammengeführt werden.

2. Nun führen wir unsere alternative Realität mit der Haupt-Zeitlinie zusammen:

git merge feature-dimension

Dieser Befehl weist Git an, alle Änderungen aus feature-dimension zu nehmen und auf master anzuwenden. Es ist, als würde man die Erkenntnisse aus der Paralleldimension in unser Hauptuniversum integrieren.

Du solltest eine Nachricht wie diese sehen:

Updating <hash1>..<hash2>
Fast-forward
 README.md              | 2 ++
 dimensional-artifact.txt | 1 +
 2 files changed, 3 insertions(+)
 create mode 100644 dimensional-artifact.txt

Diese Ausgabe zeigt dir, welche Dateien geändert wurden und wie viele Zeilen hinzugefügt oder entfernt wurden. "Fast-forward" bedeutet, dass Git den master-Branch einfach bis zu dem Punkt vorrücken konnte, an dem sich feature-dimension befand, da es keine widersprüchlichen Änderungen gab. Ein Fast-forward-Merge ist die einfachste Art des Zusammenführens und tritt auf, wenn sich der Ziel-Branch seit dem Erstellen des Quell-Branches nicht verändert hat.

Herzlichen Glückwunsch! Du hast gerade zwei Realitäten kombiniert! Die Änderungen aus feature-dimension sind nun Teil unseres Hauptuniversums. Unser interdimensionales Artefakt und die aktualisierte Dokumentation sind jetzt im master-Branch vorhanden.

3. Überprüfen wir, ob unser Artefakt den Merge überstanden hat:

cat dimensional-artifact.txt
cat README.md

Diese Befehle zeigen den Inhalt der Dateien an. Du solltest die Änderungen sehen, die wir in der feature-dimension vorgenommen haben. Damit ist bestätigt, dass der Merge erfolgreich war.

Du hast erfolgreich Entdeckungen aus einer alternativen Realität in die Haupt-Zeitlinie gebracht. Genau so integrieren Entwickler neue Funktionen in ihre Hauptprojekte! Dies ist ein Kernkonzept von Git, das es ermöglicht, isoliert an Features zu arbeiten und sie erst dann in den Hauptcode einzufügen, wenn sie bereit sind.

Wenn du eine Liste aller Branches sehen möchtest, die bereits in deinen aktuellen Branch zusammengeführt wurden, kannst du den Befehl git branch --merged verwenden. Das hilft dabei, den Überblick zu behalten, welche Entwicklungen bereits integriert sind.

Dimensionsportale schließen

Da wir unsere Entdeckungen erfolgreich in die Hauptrealität übertragen haben, können wir das Portal zu unserer alternativen Dimension schließen. In Git-Sprache bedeutet das: Wir löschen den Branch, den wir nicht mehr benötigen.

1. Schließen wir unser feature-dimension-Portal:

git branch -d feature-dimension

Das Flag -d weist Git an, den Branch zu löschen, aber nur, wenn er vollständig zusammengeführt wurde. Dies ist eine Sicherheitsmaßnahme, um den versehentlichen Verlust von nicht übernommenen Änderungen zu verhindern. Git erlaubt das Löschen mit -d nur, wenn die Änderungen im aktuellen Branch enthalten sind.

Falls du versuchen solltest, einen Branch zu löschen, der noch nicht vollständig zusammengeführt wurde, wird Git dich warnen. Wenn du dir absolut sicher bist, dass du ihn trotzdem löschen willst, kannst du das Flag -D verwenden: git branch -D feature-dimension. Dies erzwingt das Löschen ungeachtet des Merge-Status. Sei vorsichtig mit dieser Macht! Dieser Befehl sollte nur genutzt werden, wenn du die Änderungen im Branch definitiv nicht mehr brauchst.

2. Überprüfen wir, welche Realitäten noch existieren:

git branch

Du solltest jetzt nur noch den master-Branch sehen. Das bedeutet, dass das Portal zur feature-dimension nun geschlossen ist.

Das Aufräumen alter Branches hält dein Multiversum organisiert. Es ist eine gute Gewohnheit, Portale zu Dimensionen zu schließen, die nicht mehr gebraucht werden – besonders bei größeren Projekten mit vielen alternativen Realitäten. So bleibt dein Arbeitsbereich sauber und übersichtlich.

Wenn du jemals alle Branches sehen möchtest, einschließlich der Remote-Branches (Kopien von Branches auf anderen Servern), kannst du git branch -a verwenden. Das ist besonders nützlich, wenn du mit anderen Dimensionen-Springern zusammenarbeitest.

Zusammenfassung

Herzlichen Glückwunsch, Meister des Multiversums! Du hast gerade deinen Crashkurs in Git-Branch-Zauberei abgeschlossen. Lassen wir die unglaublichen Taten, die du vollbracht hast, noch einmal Revue passieren:

1. Du hast einen Hub für unendliche Möglichkeiten erschaffen (ein neues Git-Repository).
2. Du hast ein Portal zu einer alternativen Realität geöffnet (einen neuen Branch erstellt).
3. Du hast gelernt, zwischen verschiedenen Dimensionen hin- und herzuspringen (Branches wechseln mit git checkout oder git switch).
4. Du hast bahnbrechende Entdeckungen in einem Paralleluniversum gemacht (Änderungen in einem separaten Branch committet).
5. Du hast zwei Realitäten verschmolzen und deine Entdeckungen in die Haupt-Zeitlinie gebracht (Branches gemergt).
6. Schließlich hast du gelernt, wie man Dimensionsportale schließt, die nicht mehr benötigt werden (Branches löschen).

Diese multiversalen Fähigkeiten sind für jeden zeitreisenden Entwickler von entscheidender Bedeutung. Durch die Verwendung von Branches kannst du:

• An verschiedenen Funktionen oder Fehlerbehebungen in Paralleluniversen arbeiten, ohne die Haupt-Zeitlinie zu stören.
• Mit gewagten Ideen in sicheren, alternativen Realitäten experimentieren.
• Mit anderen dimensionsspringenden Entwicklern zusammenarbeiten, wobei jeder in seiner eigenen Realität arbeitet.
• Deine Haupt-Zeitlinie stabil und fehlerfrei halten und neue Funktionen erst dann mergen, wenn sie wirklich fertig sind.

Viel Spaß beim Springen zwischen den Dimensionen, und mögen deine Merges immer konfliktfrei sein!