Diskussionsfaden hier: Diskussionsthread: Git: Grundlagen, Branches, Best-Practices und mehr

Präambel
Moin zusammen,

Im Forum habe ich immer wieder gesehen, dass Leute sich nicht mit Git (oder Versionskontrolle allgemein) richtig auskennen, oder gar erst nichts davon wissen.
Egal ob ihr open- oder closed-source Software verwendet, ist eine vernünftige Versionskontrolle immer sinnvoll.

Es gibt diverse Produkte auf dem Markt, wie zum Beispiel Mercurial oder Subversion, die in diesem Thema allerdings nicht behandelt werden.
Viele Tipps und Informationen treffen genau so auf diese zu; die genaue Funktionsweisen unterscheiden sich allerdings teils massiv.

Ich bin nicht qualifiziert, Tipps und Informationen über andere Versionskontrollsysteme als Git zugeben und müsste genau so eine Suchmaschine verwenden, wie ihr.

Dieses Thema wird sich umfassend mit der Kommandozeilenanwendung git auseinandersetzen!
Grundsätzlich könnt ihr aber alles auch in GUI-Tools wie z.B. GitKraken anwenden.

Folgende Nomenklatur werde ich beim Schreiben von Befehlen verwenden:


01. Grundlagen - Was ist Git und wofür brauche ich das?

Git ist wie oben beschrieben ein Versionskontrollsystem. Es wird verwendet, um Änderungen in/an eurem Quellcode so zu verwalten, dass ihr zu jeder Zeit sehen könnt, wer was gebaut (oder auch verbaselt) hat.
Verwaltet werden eure Dateien in sogenannten Repositories. Diese sind einfache Ordner mit einigen bestimmten und wichtigen Dateien und Unterordnern, die Git für das Tracking benötigt.

Repositories bestehen aus zwei grundsätzlichen Stücken: local und remote.

Das local Repo ist das, was bei euch auf dem Rechner sitzt, womit ihr eure tägliche Arbeit erledigt.
Das remote liegt auf einem Git-Server und wird dort verwaltet/gehostet.

Diese beiden Repos können unabhängig voneinander geändert werden; diese Änderungen müssen jedoch zusammen synchronisiert (gemerged) werden. Dies geschieht entweder über Pull Requests, oder direkte Branch-Merges.

Diese strikte Trennung erlaubt es euch, dass ihr vorerst völlig unabhängig vom remote arbeiten könnt.

Um Dateien voneinander zu trennen und Unterschiede zwischen Versionen zu erkennen, bildet Git Hash-Werte der Dateien, die in dem Repository liegen und die "angemeldet" wurden.

02. Installation

Die Installation von Git ist auf allen großen Plattformen einfach. Für Linux und macOS ist Git in allen Packetverwaltungen; für neuere Versionen von Windows kann git mittels winget installiert werden (empfohlen).
In diesem Thread werde ich ausschließlich die Linux-Git-Variante verwenden. Die Befehle sind allerdings auf allen Plattformen gleich.

02.1 Klassiche Windows-Installation

Die klassische Variante, Git zu installieren, ist sich von git-scm.org die neueste Version des Git Bash herunterzuladen und unter Windows zu installieren.

Ich empfehle hier, Git ins System-PATH zu installieren, sodass ihr von jedem Powershell- oder CMD-Fenster darauf zugreifen könnt.
Für erfahrene Nutzer wird hier das Git Bash mitinstalliert, welches eine Linux-ähnliche Shell installiert, mit den POSIX-Standard-Toolset (vi, cat, less, etc.)

02.2 Moderne Windows-Installation

Moderne Versionen von Windows (Windows 10/11) bieten seit einiger Zeit WinGet an; dies ist ein Windows-eigenes Paketverwaltungstool, ähnlich zu NuGet.

WinGet kann über ein Powershell-Fenster verwendet werden:



02.3 Linux-Installation

Je nach Linux-Distro, werden unterschiedliche Paketverwalter verwendet.

Debian, Ubuntu, Linux Mint, ...: $ sudo apt install git
Fedora, RHEL, CentOS: $ sudo yum install git
Arch: $ sudo pacman -S git

02.4 macOS-Installation

Auf macOS empfehle ich, Git über brew zu installieren: % brew install git

03. Ein leeres Repository anlegen

Zuerst beschäftigen wir uns mit dem local Repo. Repos können lokal angelegt (initialisiert) werden und danach mit einem remote verknüpft werden.
Dies ist meine (persönliche) bevorzugte Variante, ein Repo anzulegen. So kann ich in Ruhe offline arbeiten und eine erste Version eines Projekts bauen, bevor es hochgeladen wird. So kann ich im Zweifel das Projekt folgenlos löschen und neubeginnen, sollte das nötig sein.

Zuerst suche ich mir einen Ort, an dem meine Repos angelegt werden sollen. Üblicherweise habe ich hierfür einen source-Ordner unter meinem Benutzerverzeichnis: /home/simon/source

Mit dem Befehl git init <project_name> kann ich nun ein frisches Git-Repo anlegen.
Git wird dann einen gleichnamigen Ordner erstellen und darin folgende Ordner/Dateien anlegen:


Zugleich wird auch der Haupt-"Branch" angelegt; in meinem Fall ist das "master" - je nach Konfiguration/Richtlinie könnte der bei euch erstellte Branch auch anders heißen, z.B. "main".

Für den Anfang müsst ihr nichts in dem .git-Ordner machen. Wichtig zu wissen ist nur: hier speichert Git alle Hashes eurer Dateien, Branches und weitere Meta-Infos zum Repo ab, wie z.B. wo der remote liegt.

Hierin könnt ihr nun arbeiten und einen Prototypen erstellen. Git weiß allerdings noch nicht, welche Dateien es überwachen soll. Das wird später noch kommen.

Zuerst:

04. Das Local mit dem Remote verbinden

Nun habt ihr eurer local angelegt und möglicherweise auch Dateien abgelegt; nun wollt ihr dass euer Repo auch online (firmenintern oder z.B. bei GitHub) für andere (Personen, Computer, wie auch immer) sichtbar/verwendbar ist.

Hierzu müsst ihr zuerst bei eurem Git-Server ein Repository anlegen.

WICHTIG: Wenn ihr das Repo lokal angelegt habt, bevor es ein remote gab, dann seht davon ab, das Repo online zu initialisieren.
In dem u.a. Screenshot seht ihr, dass ich alle Optionen abgewählt habe.



Tipp: Der Name eures remotes muss nicht dem gleichen, was ihr als local erstellt habt. Das ist Git völlig egal.



GitHub zeigt euch netterweise direkt an, welche Befehle ihr ausführen müsst, um die beiden Repos miteinander zu verknüpfen.

Grundsätzlich braucht ihr nur diesen Befehl, solltet ihr euch für diese Variante entschieden haben:


Nun sind beide Repos miteinander verknüpft und können miteinander synchronisiert werden.

05. Ein bestehendes oder neues Repo klonen

Neben der oben aufgeführten Variante, kann man bei GitHub auch ein Repo initialisieren, sodass man das Repo einfach klonen kann.
Das funktioniert dann sowohl für neue Repos, als auch für bestehende Repos, die möglicherweise sogar noch Submodule verwenden.

Um ein bestehendes Repo zu klonen, müsst ihr nur folgenden Befehl ausführen:



Wie ihr seht, habe ich noch den Switch --recursive übergeben. Das sorgt dafür, dass das Repo und alle Submodule (weitere Repos, innerhalb des Hauptrepos) mitgeklont werden. So spart man sich am Ende dumme Fehler, wenn gewisse Ordner direkt nach dem Klonen leer sind.
Da ich das vorhin erstellte (nicht initialisierte) Repo erneut geklont habe, gibt git mir eine Warnung, dass in dem Repo nichts enthalten ist. Das ist nicht weiter schlimm und kann in den meisten Fällen ignoriert werden.

06. Irrelevante Dateien ignorieren

Git erlaubt es, eine vielzahl an verschiedenen Dateien zu indizieren und verwalten. Dazu gehören Bilder, BLOBs, Binaries in Form von Object-Code oder Anwendungen und vieles, vieles mehr.
Es ist jedoch nicht immer sinnvoll, alle Dateien von Git verwalten zu lassen.

Folgende Regeln sollten beachtet werden, damit ihr euer Repo nicht zumüllt und am Ende niemand unnötigen Schrott herunterladen muss, den er sowieso beim nächsten Build ersetzt.

Hierzu bietet git sog. .gitignore-Dateien an. Diese können in jeden Ordner innerhalb des Repos angelegt werden und gelten dann für den und alle Unterordner.

Datei-Struktur:


Regeln (Best Practice)/Zu ignorierende Dateien/Ordner:

• Unwichtige oder persönliche IDE Einstellungen sollten nicht mitversioniert werden
  • Deine Lieblingsfarben interessieren mich nicht
  • Ausnahmen: Coding-Richtlinien, Build-/Debug-Einstellungen
    
• Build-Artefakte
  • Liefer sie nicht mit, die kann ich mir selber bauen
• Test-/Debug-Daten
  • Ausnahmen: Daten, die zwingend für deine automatisierten Tests notwendig sind
  • Test-Daten sollten nach Möglichkeit prozedural generiert werden

07. Dateien zur Versionskontrolle hinzufügen

In einem leeren Repository, wird git erstmal keine Dateien überwachen. Das ist, damit ihr entscheiden könnt, welche Dateien versioniert werden müssen und welche nicht.
Git kann entweder einzelne oder gleichzeitig mehrere Dateien (und Ordner) zur Überwachung aufnehmen.

Werden Dateien zur Überwachung hinzugefügt, werden diese allerdings nicht gleich gehashed und diese sind dann auch nicht in dem remote.
Alle Änderungen sind in dem local und können sehr einfach reversiert werden.

07.1 Einzelne Dateien zur Versionskontrolle aufnehmen

Mit dem Befehl $ git add <filename> könnt ihr einzelne Dateien zur Versionskontrolle hinzufügen.

07.2 Mehrere Dateien zur Versionskontrolle hinzufügen

Den obigen Befehl kann mit beliebig vielen Dateien erweitert werden, um gleichzeitig mehrere Dateien hinzuzufügen: $ git add <filename0> [<filename1> [<filename2> [...]]]

07.3 Alle Dateien zur Versionskontrolle hinzufügen

Wenn ihr eure .gitignore richtig eingestellt habt, könnt ihr bedenkenfrei alle übrigens Dateien zur Versionskontrolle hinzufügen: $ git add --all

08. Dateien committen

Nun habt ihr eure Dateien hinzugefügt, die wichtigsten Schritte sind erledigt. Nun müsst ihr mit git ein Hash der Datei(en) erstellen. So könnt ihr dann später die Unterschiede zwischen den Versionen sehen.
Dazu müsst ihr einen "Commit" durchführen; dieser kann entweder mit einzelnen Dateien oder über das ganze Repo erfolgen.

Ein Commit beinhaltet nicht nur die Änderungen an den Dateien, sondern auch ein Kommentar von euch, in dem ihr beschreiben könnt, was ihr seit dem letzten Stand gemacht habt.

So könnt ihr (oder andere Entwickler) auf einem Blick sehen, was geschehen ist, ohne dass die sich mühselig durch alle Dateiänderungen fuchsen müssen.

Der Commitbefehl hat folgende Struktur:


Ihr könnt den -m "" Parameter weglassen, dann werdet ihr allerdings zu einem Texteditor weitergeleitet, wo ihr die Commitnachricht bearbeiten müsst.

Das sieht z.B. so aus:



Wir ihr seht, sind unten einige Zeilen mit Rauten. Diese werden von git ignoriert und sind nur zu eurer Info.
Alle Zeilen, die nicht mit einer Raute beginnen, sind dann eure Commitnachricht. Ich persönlich schreibe sie oben weil es einfacher und schneller geht.

09. Repo mit dem Server synchronisieren

Eure Dateien sind soweit, dass sie zum Server übertragen werden können.

Hierzu könnt ihr nun den Befehl $ git push verwenden:


Wir ihr seht, wurde auf dem Server nun auch ein neuer Branch erstellt, der eure Änderungen enthält.
Für alle Branches und Tags die ihr erstellt ist das Verfahren gleich oder sehr ähnlich.

10. Was genau sind Branches und wofür brauche ich sie?

Grundsätzlich möchte man in der Entwicklung seinen funktionalen Stand von dem instabilen Stand trennen; mit git geht dies mittels Branches.
Ihr müsst euch das Repo wie ein Baum vorstellen.

Anbei ein Beispielbild aus einem meiner Repos:


Ihr habt einen "Stamm", also einen Hauptzweig für euren Code.
Nach Best Practice wird in diesem Branch nicht entwickelt. (Bei Bedarf würde ich noch einen Beitrag erstellen, wo Branching-Modelle genauer erklärt würden!)

Stattdessen, zweigt ihr von dem Hauptzweig ab und führt die nach eurer Entwicklungsphase wieder zusammen.
Dieses Vorgehen hat den Vorteil, dass eure Entwicklungsversionen von dem stabilen Zweig entfernt sind und dort auch nichts kaputtmachen können.
Branches können jederzeit erstellt und wieder gelöscht werden.

Einige Regeln sollte man noch berücksichtigen:

• Verwendet sinnvolle Namen für eure Branches!
  
• Je nachdem, ob es sich um einen Entwicklungs-, Hotfix- oder PoC-Branch handelt, verwendet andere Präfixe
  
  • feat/mein-feature-branch
    
  • fix/mein-reparier-branch
    
  • poc/mein-proof-of-concept-branch
    
• Schreibt Branchnamen im lower-kebap-case und haltet es einheitlich
  
  • So könnt ihr Branchnamen von z.B. Tags unterscheiden
    
• Vermeidet ewige Branches.
  
  • Branches sollten möglichst kurzlebig sein und so schnell wie möglich zurück in den Hauptzweig geführt werden, sodass die Unterschiede zwischen den Codebasen nicht zu groß werden, dass ein Merge nicht sinnvoll machbar ist!

10.1 Einen neuen Branch erstellen

Um unter git einen Branch zu erstellen, führt folgenden Befehl aus: git checkout -b <"new_branch_name">.
Wichtig zu wissen ist, dass git immer ab genau dem Punkt einen neuen Branch erstellt, an dem ihr euch befindet! Habt ihr ein Branch oder Tag ausgecheckt, wird genau der aktuelle, lokale, Stand als Abzweigpunkt verwendet!

10.2 Zwischen Branches wechseln

Es kann immer mal vorkommen, dass man zwischen Branches wechseln muss. Hierfür könnt ihr den Befehl: git checkout <branch_name> verwenden.

10.3 Alle Branches anzeigen

Um alle Branches anzuzeigen, führt den Befehl git branch.
Git wird euch den Branch, auf dem ihr euch aktuell befindet, mit einem Stern (*) markieren.

10.4 Branches zusammenführen

Sollen zwei Branches zusammengeführt werden, müssen erstmal alle Änderungen committed werden.
Ist das geschehen, ist es am einfachsten, man wechselt zum Zielbranch, vor dem Merge.

Sobald das getan ist, kann ein beliebiger Branch in den aktuellen mit dem Befehl git merge <branch_name> geführt werden.

Vorerst-Abschluss

Ich hoffe ich konnte euch hiermit einiges erklären und zeigen.
Je nachdem, wie das ankommt, würde ich es mit euren Fragen und Anregungen erweitern. Git hat noch sehr viel mehr zu bieten, wie z.B. Tags, den Stash, Pull Requests und vieles mehr.

Bis dahin hoffe ich, dass das nicht zu viel Text war!

Habt ihr Verbesserungsvorschläge, schreibt mich gerne an und ich werde sie übernehmen, wenn sinnvoll.

Happy Coding!