Einrichtung¶

Vor Arbeitsbeginn sollte man den eigenen Namen und eine E-Mail-Adresse eintragen:

git config --global user.name NAME
git config --global user.email EMAIL@ADRESSE.de 

Diese Daten erscheinen in der Beschreibung einer Veränderung und dienen der Identifizierung des Autors einer Revision, falls mehrere Entwickler an einem Projekt arbeiten. Enthalten die config-Werte Leerzeichen (z.B. Vorname und Nachname), so müssen sie in Anführungszeichen gesetzt werden, z.B.:

git config --global user.name "VORNAME NACHNAME" 

Überprüfen kann man die Parameter ohne Angabe des Wertes, z.B.:

git config --global user.name 

Um die Lesbarkeit zu erhöhen, sollte man die Ausgaben mit den folgenden Befehlen einfärben:

git config --global color.ui "auto" 

Für Computer mit mehreren Prozessorkernen empfiehlt sich diese Option:

git config --global pack.threads "0" 

Wenn innerhalb eines Repository abwechselnd auf Linux/Mac oder Windows gearbeitet wird empfiehlt es sich, folgende Konfigurationen hinzuzufügen, um Zeilenenden zuverlässig zu handhaben.

Für Linux/Mac

git config --global core.autocrlf input 

Für Windows

git config --global core.autocrlf true 

Wenn ein anderer Editor (Voreinstellung ist Nano), z.B. für mehrzeilige Commits, verwendet werden soll, nutzt man folgende Konfiguration:

Für VSCode

git config --global core.editor "code --wait" 

Für nvim

git config --global core.editor nvim 

Folgender Befehl öffnet den eingestellten Editor mit der Standard-Konfigurationsdatei:

git config --global -e 

Weiterhin empfiehlt es sich, als Standard-Branch main anstatt master zu verwenden (siehe: Empfehlung von GitHub). Um sicherzustellen, dass in neuen Repositories main verwendet wird sollte man folgende Konfiguration hinzufügen:

git config --global init.defaultBranch main 

Grundlagen¶

Zuerst erstellt man einen Ordner für das Projekt und wechselt in diesen Ordner. Dort führt man nun den Befehl

git init 

aus. Der Befehl erstellt das Git-Repositorium mit den nötigen Angaben. Nun erstellt man den Quellcode des Programms und fügt die Datei(en) mit dem Befehl

git add DATEI 

zum Git-Repository hinzu. Hat man nun wieder etwas am Quellcode verändert, erstellt man mit

git commit -m "ÄNDERUNGSBESCHREIBUNG" 

eine Revision.

Stellt man nach einem Commit fest, dass eine Datei vergessen wurde, kann diese mit den folgenden beiden Befehlen dem vorangegangenen Commit noch hinzugefügt werden:

git add VERGESSENE_DATEI
git commit --amend 

Wobei dieses Vorgehen nicht zu empfehlen ist, wenn das Repository bereits veröffentlicht wurde (siehe folgender Absatz zum Befehl push).

Will man den Quellcode nun auf einen Server laden, führt man diesen Befehl aus:

git push ADRESSE BRANCHNAME 

Hat nun ein anderer Entwickler den Quellcode verändert, kann man die lokale Version mit dem Befehl

git pull 

aktualisieren.

Wenn man nun etwas am Quellcode verändert oder einen Patch eingespielt hat, dies aber rückgängig machen möchte, benutzt man

git restore --staged <Datei> 

um einzelne Dateien aus der Staging Area zu entfernen oder

git restore --staged . 

um alle Dateien aus der Staging Area zu entfernen, bevor man einen Commit durchführt.

Alternativ

git reset --hard 

Dieser Befehl setzen alle unbestätigten lokalen Veränderungen zurück. Mit dem nächsten Befehl kann man auflisten, welche Dateien sich gerade in der Staging Area befinden:

git ls-files 

Möchte man eine Datei aus dem Repository löschen, die man im lokalen Verzeichnis gelöscht hat, verwendet man ebenfalls git add

git add <DATEI> 

Dadurch erkennt Git, dass die Datei im lokalen Verzeichnis nicht mehr vorhanden ist und entfernt sie aus der Staging Area. Mit dem nächsten git commit ist die Datei in der nächsten Revision gelöscht.

Der Befehl git rm löscht die angegebene Datei sowohl aus der Staging Area als auch auf dem Dateisystem! Man kann mehrere Dateien gleichzeitig oder Patterns angeben.

git rm <DATEI>
git rm <DATEI1> <DATEI2> <DATEI3>
git rm *.txt 

Auslassen mit .gitignore¶

Der Befehl git add . fügt alle Dateien innerhalb des von Git verwalteten Verzeichnisses zur Staging Area hinzu. Hier kann man viel falsch machen und ein Repository mit unnötigen Dateien aufblähen, oder versehentlich Passwörter oder SSH-Keys veröffentlichen. Möchte man bestimmte Dateien oder ganze Verzeichnisse davon ausschließen, muss man die Datei .gitignore anlegen. Das ist zum Beispiel dann sinnvoll, wenn eine IDE ein Verzeichnis anlegt, welches mit dem eigentlichen Projekt nichts zu tun hat, wenn ein Compiler temporäre Dateien oder kompilierte Binaries in einem Verzeichnis ablegt oder wenn man wichtige Informationen wie Passwörter in einer Datei ablegt, die nicht öffentlich verfügbar sein dürfen.

Ein Beispiel, das für jedes Projekt angepasst werden kann:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# generic files to ignore
# backup files (*~) and vim swap file (.swp), MacOS dir file (.DS_Store)
*~
*.lock
*.DS_Store
.*.swp
*.out

# IDE files to ignore (Netbeans, Eclipse)
nbproject/private/
.classpath
.project
.settings

# ignore generated .class files
*.class

# except this file
!.gitignore

Weitere Beispiele für viele Sprachen findet man auf GitHub. Weiterführende Artikel findet ihr dort in der README-Datei.

Branches¶

Hat man mehrere Entwicklungszweige zu pflegen (bspw. stable und testing), kann man sich der Branches bedienen. Um bestehende Branches anzuzeigen, gibt man diesen Befehl ein:

git branch 

Zum Anzeigen von remote Branches gibt man ein:

git branch -r 

Um nun einen neuen Branch zu erstellen, muss nur der folgende Befehl eingegeben werden:

git branch BRANCHNAME 

Um in eine anderen Branch zu wechseln, verwendet man diesen Befehl:

git checkout BRANCHNAME 

Das Löschen von local und remote Branches geschieht folgendermaßen:

local:

git branch -d THE_LOCAL_BRANCH 

remote:

git push origin :THE_REMOTE_BRANCH 

Patch erstellen¶

Ein git-Commit kann recht einfach, z.B. mit

git format-patch cfe0a421d7d334499fb5de4ab2c4e2178a4630f3 --stdout > PATCHDATEI.patch 

in einen Patch (namens PATCHDATEI.patch) verwandelt werden. Der Commit-Hash (z.B. cfe0a421d7d334499fb5de4ab2c4e2178a4630f3) ist entsprechend anzupassen. Mit folgendem Befehl kann der Patch dann angewandt werden:

patch -p1 < PATCHDATEI.patch