Ist Ihnen aufgefallen, dass Git für die Arbeit mit Code so wichtig ist, dass die Leute es kaum in ihren Tech-Stack oder in ihren Lebenslauf aufnehmen? Die Annahme ist, dass Sie es bereits wissen, oder zumindest genug, um durchzukommen, aber tun Sie das auch? Git ist ein Versionskontrollsystem (VCS). Die allgegenwärtige Technologie, die es uns ermöglicht, Code zu speichern, zu ändern und mit anderen gemeinsam daran zu arbeiten.

Ärzte haben Stethoskope.
Mechaniker haben Schraubenschlüssel.
Wir Entwickler haben Git.

Als Entwickler dreht sich unsere tägliche Routine um das Lesen, Schreiben und Überprüfen von Code. Git ist wohl eines der wichtigsten Tools, die wir verwenden. Die Beherrschung der Features und Funktionen, die Git bietet, ist eine der besten Investitionen, die Sie als Entwickler in sich selbst tätigen können.

Legen wir die Grundlagen

Wenn Sie Git nicht richtig lernen, laufen Sie Gefahr, sich ständig am Kopf zu kratzen, bei denselben Problemen hängen zu bleiben oder den Tag zu bereuen, an dem Sie einen weiteren Merge-Konflikt in Ihrem Terminal sehen. Lassen Sie uns sicherstellen, dass dies nicht passiert, indem wir einige grundlegende Git-Konzepte definieren.

Branches

In einem Git-Repository finden Sie eine Hauptentwicklungslinie, die in der Regel als „main“ oder „master“ (veraltet) bezeichnet wird und von der mehrere Zweige abweichen. Diese Branches stellen gleichzeitige Arbeitsströme dar, die es Entwicklern ermöglichen, mehrere Funktionen oder Korrekturen gleichzeitig innerhalb desselben Projekts durchzuführen.

Commits

Git-Commits dienen als Bündel von aktualisiertem Code, die einen Snapshot des Projektcodes zu einem bestimmten Zeitpunkt erfassen. Jeder Commit zeichnet Änderungen auf, die seit dem letzten Commit aufgezeichnet wurden, und bildet so einen umfassenden Verlauf der Entwicklungsphase des Projekts.

Wenn Sie Commits referenzieren, verwenden Sie in der Regel den eindeutig identifizierten kryptografischen Hash.

Beispiel:

git show abc123def456789

Hier werden detaillierte Informationen über den Commit mit diesem Hash angezeigt.

Head

Der letzte Commit im aktuell ausgecheckten Zweig wird durch das HEAD gekennzeichnet, das als Zeiger auf eine beliebige Referenz innerhalb des Repositorys dient. Wenn Sie sich in einem bestimmten Branch befinden, verweist dies auf den letzten Commit in diesem Branch. Anstatt auf die Spitze eines Zweigs zu zeigen, kann manchmal direkt auf einen bestimmten Commit ( detached Zustand) gezeigt werden.

Stages

Das Verständnis von Git-Phasen ist entscheidend für die Navigation in Ihrem Git-Workflow. Sie stellen die logischen Übergänge dar, an denen Änderungen an Ihren Dateien vorgenommen werden, bevor sie in das Repository übernommen werden. Schauen wir uns das Konzept der Git-Phasen an:

Working Directory

Hier können Sie Dateien für Ihr Projekt bearbeiten, ändern und erstellen. Working directory stellt den aktuellen Status Ihrer Dateien auf Ihrem lokalen Computer dar.

Staging Area

Der Bereich staging ist wie ein Wartebereich oder eine Pre-Commit-Zone, in der Sie Ihre Änderungen vorbereiten, bevor Sie sie an das Repository übergeben.

Nützlicher Befehl hier: git add Auch git rm kann verwendet werden, um Änderungen rückgängig zu machen

Lokales Repository

Das lokale Repository ist der Ort, an dem Git die festgeschriebenen Änderungen dauerhaft speichert. Es ermöglicht Ihnen, den Verlauf Ihres Projekts zu überprüfen, zu früheren Zuständen zurückzukehren und mit anderen an derselben Codebasis zusammenzuarbeiten.

Sie können Änderungen, die im Staging-Bereich bereit sind, wie folgt übernehmen: git commit

Entferntes Repository

Das Remote-Repository ist ein zentraler Ort, der in der Regel auf einem Server (wie GitHub, GitLab oder Bitbucket) gehostet wird und an dem Sie Ihr Projekt freigeben und mit anderen zusammenarbeiten können.

Sie können Befehle wie und verwenden, um Ihre festgeschriebenen Änderungen aus Ihrem lokalen Repository in das Remote-Repository zu pushen/pullen.git pushgit pull

Erste Schritte mit Git

Nun, Sie müssen irgendwo anfangen, und in Git ist das Ihr workspace. Sie können ein vorhandenes Repository oder eine Kopie dieses Arbeitsbereichs erstellen, oder wenn Sie in einem neuen lokalen Ordner auf Ihrem Computer völlig neu beginnen, müssen Sie ihn mit git init in ein Git-Repository umwandeln. Der nächste Schritt, der nicht zu übersehen ist, ist die Einrichtung Ihrer Anmeldeinformationen.

Übersicht git — Quelle: https://li.earthonline.us/

Anmeldeinformationen eingerichtet

Wenn Sie Push und Pull zu einem Remote-Repository ausführen, möchten Sie nicht jedes Mal Ihren Benutzernamen und Ihr Passwort eingeben müssen, vermeiden Sie dies, indem Sie einfach den folgenden Befehl ausführen:

git config --global credential.helper store

Wenn Sie zum ersten Mal mit dem Remote-Repository interagieren, werden Sie von Git aufgefordert, Ihren Benutzernamen und Ihr Kennwort einzugeben. Und danach werden Sie nicht mehr aufgefordert

Es ist wichtig zu beachten, dass die Anmeldeinformationen in einem Klartextformat in einer Datei (.git-credentials) gespeichert werden.

Um die konfigurierten Anmeldeinformationen zu überprüfen, können Sie den folgenden Befehl verwenden:

git config --global credential.helper

Arbeiten mit Branches

Wenn Sie lokal arbeiten, ist es wichtig zu wissen, in welchem Zweig Sie sich gerade befinden. Diese Befehle sind hilfreich:

# Will show the changes in the local repository
git branch 
# Or create a branch directly with
git branch feature-branch-name

Um zwischen Zweigen zu wechseln, verwenden Sie:

git switch

Zusätzlich zum Übergang zwischen ihnen können Sie auch Folgendes verwenden:

git checkout 
# A shortcut to switch to a branch that is yet to be created with the -b flag 
git checkout -b feature-branch-name

Um den Status des Repositorys zu überprüfen, verwenden Sie:

git status

Arbeiten mit Commits

Wenn Sie mit Commits arbeiten, verwenden Sie git commit -m, um Änderungen aufzuzeichnen, git endable, um den letzten Commit zu ändern, und versuchen Sie Ihr Bestes, um die Konventionen für Commit-Nachrichten einzuhalten.

# Make sure to add a message to each commit
git commit -m "meaningful message"

Wenn Sie Änderungen an Ihrem letzten Commit vorgenommen haben, müssen Sie keinen weiteren Commit erstellen, Sie können das Flag – — amend verwenden, um den letzten Commit mit Ihren gestaffelten Änderungen zu ändern

# make your changes
git add .
git commit --amend
# This will open your default text editor to modify the commit message if needed.
git push origin your_branch --force

Seien Sie vorsichtig bei der Verwendung von --force, da dies das Potenzial hat, den Verlauf des Zielzweigs zu überschreiben. Die Anwendung auf dem Haupt-/Master-Zweig sollte generell vermieden werden.
Als Faustregel gilt, dass es besser ist, öfter zu committen, um zu vermeiden, dass der Fortschritt verloren geht oder die nicht bereitgestellten Änderungen versehentlich zurückgesetzt werden. Man kann die Historie nachträglich neu schreiben, indem man mehrere Commits zerquetscht oder ein interaktives Rebase durchführt.

Verwenden Sie git log, um eine chronologische Liste von Commits anzuzeigen, beginnend mit dem letzten Commit und zeitlich rückwärts.

Manipulation der Geschichte

Die Manipulation der Geschichte erfordert einige mächtige Befehle. Rebase schreibt den Commitverlauf neu, squashing kombiniert mehrere Commits zu einem und Cherry-picking wählt bestimmte Commits aus.

Rebasing und Zusammenführung

Es ist sinnvoll, Rebasing mit Merging zu vergleichen, da ihr Ziel das gleiche ist, sie es aber auf unterschiedliche Weise erreichen. Der entscheidende Unterschied besteht darin, dass das Rebasing die Geschichte des Projekts neu schreibt. Eine wünschenswerte Wahl für Projekte, die Wert auf eine klare und leicht verständliche Projekthistorie legen. Auf der anderen Seite werden beim Zusammenführen beide Branch-Historien beibehalten, indem ein neuer Merge-Commit generiert wird.

Während eines Rebases wird die Commit-Historie des Feature-Zweigs neu strukturiert, wenn sie in den Hauptzweig verschoben wird.

Der Arbeitsablauf ist hier ziemlich einfach.

Stellen Sie sicher, dass Sie sich auf dem Zweig befinden, den Sie rebasen möchten, und rufen Sie die neuesten Änderungen aus dem Remote-Repository ab:

git checkout your_branch
git fetch

Wählen Sie nun den Zweig aus, auf den Sie rebase möchten, und führen Sie diesen Befehl aus:

git rebase upstream_branch

Nach dem Rebasing müssen Sie möglicherweise ein Pushen Ihrer Änderungen erzwingen, wenn der Zweig bereits in ein Remote-Repository gepusht wurde:

git push origin your_branch --force

Squashing

Git-Squashing wird verwendet, um mehrere Commits in einem einzigen, zusammenhängenden Commit zusammenzufassen.

Das Konzept ist leicht zu verstehen und besonders nützlich, wenn die verwendete Methode zur Vereinheitlichung des Codes das Rebasing ist, da die Historie geändert wird und es wichtig ist, die Auswirkungen auf die Projekthistorie zu berücksichtigen. Es gab Zeiten, in denen ich Schwierigkeiten hatte, einen Squash durchzuführen, vor allem mit interaktivem Rebase, zum Glück haben wir einige Tools, die uns dabei helfen. Dies ist meine bevorzugte Methode des Quetschens, bei der der HEAD-Zeiger die Anzahl X von Commits nach hinten verschoben wird, während die bereitgestellten Änderungen beibehalten werden.

# Change to the number after HEAD~ depending on the commits you want to squash
git reset --soft HEAD~X
git commit -m "Your squashed commit message"
git push origin your_branch --force

Cherry-picking

Cherry-picking ist nützlich, um selektiv Änderungen von einem Zweig in einen anderen einzubauen, insbesondere wenn das Zusammenführen ganzer Zweige nicht wünschenswert oder machbar ist. Es ist jedoch wichtig, Cherry-picking mit Bedacht zu verwenden, da sie bei falscher Anwendung zu doppelten Commits und abweichenden Verläufen führen kann

Um dies zuerst durchzuführen, müssen Sie den Commit-Hash des Commits identifizieren, den Sie auswählen möchten, Sie können dies mit git log tun. Sobald Sie den Commit-Hash identifiziert haben, können Sie Folgendes ausführen:

git checkout target_branch
git cherry-pick <commit-hash> # Do this multiple times if multiple commits are wanted
git push origin target_branch

Erweiterte Git-Befehle

Signieren von Commits

Das Signieren von Commits ist eine Möglichkeit, die Authentizität und Integrität Ihrer Commits in Git zu überprüfen. Es ermöglicht Ihnen, Ihre Commits kryptografisch mit Ihrem GPG-Schlüssel (GNU Privacy Guard) zu signieren und Git zu versichern, dass Sie tatsächlich der Autor des Commits sind. Sie können dies tun, indem Sie einen GPG-Schlüssel erstellen und Git so konfigurieren, dass der Schlüssel beim Commit verwendet wird. Hier sind die Schritte:

# Generate a GPG key
gpg --gen-key
# Configure Git to Use Your GPG Key
git config --global user.signingkey <your-gpg-key-id>
# Add the public key to your GitHub account
# Signing your commits with the -S flag
git commit -S -m "Your commit message"
# View signed commits
git log --show-signature

Git reflog

Ein Thema, das wir noch nicht untersucht haben, sind Git-Referenzen, sie sind Zeiger auf verschiedene Objekte innerhalb des Repositorys, in erster Linie Commits, aber auch Tags und Branches. Sie dienen als benannte Punkte im Git-Verlauf, sodass Benutzer durch die Zeitleiste des Repositorys navigieren und auf bestimmte Snapshots des Projekts zugreifen können. Zu wissen, wie man in Git-Referenzen navigiert, kann sehr nützlich sein, und sie können git reflog verwenden, um genau das zu tun. Hier sind einige der Vorteile:

Wiederherstellen verlorener Commits oder Branches
Debuggen und Problembehandlung
Fehler rückgängig machen

Interaktives Rebase

Interaktives Rebase ist eine leistungsstarke Git-Funktion, mit der Sie den Commit-Verlauf interaktiv neu schreiben können. Es ermöglicht Ihnen, Commits zu ändern, neu anzuordnen, zu kombinieren oder zu löschen, bevor Sie sie auf einen Branch anwenden.

Um es zu verwenden, müssen Sie sich mit den möglichen Aktionen vertraut machen, wie z. B.:

Pick(„p“)
Reword („r“)
Edit(„e“)
Squash („s“)
Drop („d“)

Origin vs. Upstream

Origin ist das standardmäßige Remote-Repository, das beim Klonen mit Ihrem lokalen Git-Repository verknüpft ist. Wenn Sie ein Repository geforkt haben, wird dieser Fork standardmäßig zu Ihrem „Origin“-Repository.

Upstream hingegen bezieht sich auf das ursprüngliche Repository, von dem aus Ihr Repository geforkt wurde.

Um Ihr geforktes Repository mit den neuesten Änderungen aus dem ursprünglichen Projekt auf dem neuesten Stand zu halten, holen Sie sich die Änderungen aus dem „upstream“-Repository und führen sie in Ihrem lokalen Repository zusammen oder rebasen.

Um die Remote-Repositorys anzuzeigen, die Ihrem lokalen Git-Repository zugeordnet sind, führen Sie Folgendes aus:

git remote -v

Konflikte

Keine Panik, wenn Sie versuchen, einen Zweig zusammenzuführen oder neu zu rebasen, und Konflikte erkannt werden, bedeutet dies nur, dass es widersprüchliche Änderungen zwischen verschiedenen Versionen derselben Datei oder Dateien in Ihrem Repository gibt und diese (meistens) leicht gelöst werden können.

Sie werden in der Regel in den betroffenen Dateien angezeigt, in denen Git Konfliktmarkierungen <<<<<<<=======>>>>>>> einfügt, und um die widersprüchlichen Abschnitte hervorzuheben. Entscheiden Sie, welche Änderungen beibehalten, geändert oder entfernt werden sollen, und stellen Sie sicher, dass der resultierende Code sinnvoll ist und die beabsichtigte Funktionalität beibehält.

Entfernen Sie nach dem manuellen Lösen von Konflikten in den in Konflikt stehenden Dateien die Konfliktmarkierungen <<<<<<<=======>>>>>>>, und passen Sie den Code nach Bedarf an.

Speichern Sie die Änderungen in den in Konflikt stehenden Dateien, sobald Sie mit der Lösung zufrieden sind.

Beliebte Git-Workflows

Es gibt verschiedene Git-Workflows, aber es ist wichtig zu beachten, dass es keinen universell „besten“ Git-Workflow gibt. Stattdessen hat jeder Ansatz seine eigenen Vor- und Nachteile. Schauen wir uns diese verschiedenen Arbeitsabläufe an, um ihre Stärken und Schwächen zu verstehen.

Arbeitsablauf für Feature-Zweige

Jede neue Funktion oder Fehlerbehebung wird in einem eigenen Zweig entwickelt und nach Fertigstellung wieder in den Hauptzweig zusammengeführt.

Stärke: Isolierung von Veränderungen und Reduzierung von Konflikten.
Schwäche: Kann komplex werden und erfordert ein sorgfältiges Filialmanagement.

Gitflow-Arbeitsablauf

Gitflow definiert ein striktes Verzweigungsmodell mit vordefinierten Verzweigungen für verschiedene Arten von Entwicklungsaufgaben.

Es enthält langlebige Branches wie main, develop, feature-Branches, Release-Branches und Hotfix-Branches.

Stärke: Geeignet für Projekte mit geplanten Releases und langfristiger Wartung.
Schwäche: Kann für kleinere Teams zu komplex sein

Forking-Arbeitsablauf

In diesem Workflow klont jeder Entwickler das Haupt-Repository, aber anstatt Änderungen direkt darauf zu übertragen, überträgt er die Änderungen auf seinen eigenen Fork des Repositorys. Entwickler erstellen dann Pull-Requests, um Änderungen am Haupt-Repository vorzuschlagen, was eine Code-Überprüfung und Zusammenarbeit vor dem Zusammenführen ermöglicht.

Dies ist der Workflow, den wir für die Zusammenarbeit an den Open-Source-Glasskube-Repositorys verwenden.

Stärke: Fördert die Zusammenarbeit mit externen Mitwirkenden, ohne direkten Schreibzugriff auf das Haupt-Repository zu gewähren.
Schwäche: Die Aufrechterhaltung der Synchronisierung zwischen Forks und dem Hauptrepository kann eine Herausforderung darstellen.

Pull-Request-Arbeitsablauf

Ähnlich wie beim Forking Workflow, aber anstelle von Forking, erstellen Entwickler Feature-Branches direkt im Haupt-Repository.

Stärke: Erleichtert die Codeüberprüfung, die Zusammenarbeit und den Wissensaustausch zwischen Teammitgliedern.
Schwäche: Die Abhängigkeit von menschlichen Codeprüfern kann zu Verzögerungen im Entwicklungsprozess führen.

Trunk-basierte Entwicklung

Wenn Sie in einem Team sind, das sich auf schnelle Iteration und kontinuierliche Bereitstellung konzentriert, können Sie die Trunk-basierte Entwicklung verwenden, bei der Entwickler direkt am Hauptzweig arbeiten und kleine und häufige Änderungen vornehmen.

Stärke: Fördert schnelle Iterationen, kontinuierliche Integration und den Fokus auf kleine, häufige Änderungen an der Produktion.
Schwäche: Erfordert robuste automatisierte Test- und Bereitstellungspipelines, um die Stabilität des Hauptzweigs zu gewährleisten, ist möglicherweise nicht für Projekte mit strengen Release-Zeitplänen oder komplexer Funktionsentwicklung geeignet.

Was ist die Gabel (Fork)?

Forking wird für die Zusammenarbeit an Open-Source-Projekten dringend empfohlen, da Sie die vollständige Kontrolle über Ihre eigene Kopie des Repositorys haben. Sie können Änderungen vornehmen, mit neuen Funktionen experimentieren oder Fehler beheben, ohne das ursprüngliche Projekt zu beeinträchtigen.

Deshalb auch dann, wenn Sie in Ihr Ursprungs-Repository pushen. Ihre Änderungen werden auch auf der Fernbedienung angezeigt.

Git-Spickzettel

Anstelle eines Fazits hier ein Spickzettel für Git mit den wichtigsten Befehlen.

# Clone a Repository
git clone <repository_url>

# Stage Changes for Commit
git add <file(s)>

# Commit Changes
git commit -m "Commit message"

# Push Changes to the Remote Repository
git push

# Force Push Changes (use with caution)
git push --force

# Reset Working Directory to Last Commit
git reset --hard

# Create a New Branch
git branch <branch_name>

# Switch to a Different Branch
git checkout <branch_name>

# Merge Changes from Another Branch
git merge <branch_name>

# Rebase Changes onto Another Branch (use with caution)
git rebase <base_branch>

# View Status of Working Directory
git status

# View Commit History
git log

# Undo Last Commit (use with caution)
git reset --soft HEAD^

# Discard Changes in Working Directory
git restore <file(s)>

# Retrieve Lost Commit References
git reflog

# Interactive Rebase to Rearrange Commits
git rebase --interactive HEAD~3

Mehr zu Git: Git, GitHub und GitLab

Der ultimative Guide zu Git