[[Vorlage(Getestet, focal, noble)]]

{{{#!vorlage Wissen
[:Pakete_installieren: Installation von Programmen]
[:Paketquellen_freischalten/PPA: Verwenden eines PPAs] optional
[:Terminal: Ein Terminal öffnen]
}}}

[[Inhaltsverzeichnis()]]

[[Bild(git_logo.png, 64, align=left)]]
[https://git-scm.com/ Git] {en} ist ein dezentrales [:Versionsverwaltung:Versionsverwaltungssystem]. Es wurde 2005 von [wikipedia:Linus_Torvalds:Linus Torvalds] als Ersatz für das damals proprietäre Programm [https://www.bitkeeper.com/ BitKeeper] {en} geschrieben, da BitKeeper vielen Kernel-Entwicklern durch Lizenzverschärfungen den Zugang zu den Kernelquellen verwehrte. Seit dem Entwicklungsstart hat sich Git äußerst rasant entwickelt.

Git unterscheidet sich von einem traditionellen Programm wie [:Archiv/Subversion:Subversion]. Wichtige Eigenschaften sind:

 * Einfache und effiziente Arbeitsweise nach dem [wikipedia:KISS-Prinzip:]
 * Kein zentraler Server benötigt (wird aber dennoch häufig eingesetzt)
 * Unterstützung vieler Übertragungsprotokolle (HTTP, HTTPS, FTP, SSH, rsync, lokal, Git)
 * Absicherung durch [:GnuPG:]-Signierung 
 * Umfangreiche Arbeiten ohne Internetzugang möglich

= Installation =
Folgendes Paket muss installiert [1] werden:

{{{#!vorlage Paketinstallation
git
}}}

Optional können zahlreiche Erweiterungen wie z.B. [:Grafische Oberflächen für Git:] installiert werden.

== PPA ==
Für die aktuelle Git-Version kann ein "Personal Package Archiv (PPA) [2] genutzt werden.

[[Vorlage(PPA, git-core, ppa)]]

Nach dem Aktualisieren der Paketquellen kann das folgende Paket installiert werden:

{{{#!vorlage Paketinstallation
git, ppa
}}}

== Selbst kompilieren ==
Wenn man die neueste Version von Git verwenden will, kann man Git auch selbst kompilieren.

{{{#!vorlage Builddeps
git
}}}

Danach führt man folgende Befehle [3] aus:

{{{#!vorlage Befehl
git clone git://github.com/git/git
cd git
make
make install
}}}

Dadurch wird Git in '''~/bin/''' installiert (`make install` sollte nicht mit Root-Rechten ausgeführt werden). Diese Vorgehensweise wird von Linus Torvalds empfohlen.

Wer git erst kompilieren muss um ein lauffähiges git zu bekommen, kann das Problem durch [:wget:] umgehen:

{{{#!vorlage Befehl
wget https://github.com/git/git/archive/master.zip
unzip master.zip
cd git-master
make
make install
}}}

= Anwendung =
== Hilfe zu allen Git Kommandos ==
Wenn man einmal nicht weiter weiß kann man für jedes Git Kommando eine Hilfe mit allen verfügbaren Optionen anzeigen lassen.

{{{#!vorlage Befehl
git <BEFEHL> -h
}}}

Ein Beispiel:
{{{#!vorlage Befehl
git add -h
}}}

== Index oder Staging Area? ==
Die ''Staging Area'' ist ein Sammelbereich für alle Änderungen, bevor sie mit einem Commit in Git übernommen werden. Früher wurde hierfür der Begriff ''Index'' verwendet. Dieser Begriff taucht jedoch noch überall in der Git-Dokumentation oder in der Git-Hilfe auf.

Ein Beispiel:
{{{#!vorlage Befehl
git rm -h
}}}

Selbst in der aktuellen Version von Git, in diesem Fall ''2.46.0'' (Stand September 2024), taucht noch der alte Begriff "Index" auf. Beide Begriffe, "Index" und "Staging Area", sind jedoch identisch.

== Quellcode herunterladen ==
Will man nur den Quellcode eines Projekts aus dem Git-Repositorium herunterladen, verwendet man den Befehl:

{{{#!vorlage Befehl
git clone git://ADRESSE 
}}}

Um beispielsweise den aktuellen Quellcode des Linux-Kernels in das Verzeichnis '''linux''' herunterzuladen, braucht man diesen Befehl:

{{{#!vorlage Befehl
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
}}}

Falls eine Firewall aktiv ist und der Zugriff über den Port `9418` gesperrt ist, kann man versuchen, über den fast immer offenen Port `443` und somit über das HTTP(S)-Protokoll auf selbiges zuzugreifen. Der entsprechende Befehl sieht folgendermaßen aus:

{{{#!vorlage Befehl
git clone https://ADRESSE 
}}}

== Entwicklung mit Git ==
=== Einrichtung ===
Vor Arbeitsbeginn sollte man den eigenen Namen und eine E-Mail-Adresse eintragen:

{{{#!vorlage Befehl
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.:
 
{{{#!vorlage Befehl
git config --global user.name "VORNAME NACHNAME"
}}}

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

{{{#!vorlage Befehl
git config --global user.name
}}}

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

{{{#!vorlage Befehl
git config --global color.ui "auto"
}}}

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

{{{#!vorlage Befehl
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
{{{#!vorlage Befehl
git config --global core.autocrlf input
}}}

Für Windows
{{{#!vorlage Befehl
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
{{{#!vorlage Befehl
git config --global core.editor "code --wait"
}}}

Für nvim
{{{#!vorlage Befehl
git config --global core.editor nvim
}}}

Folgender Befehl öffnet den eingestellten Editor mit der Standard-Konfigurationsdatei:
{{{#!vorlage Befehl
git config --global -e
}}}

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

{{{#!vorlage Befehl
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

{{{#!vorlage 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

{{{#!vorlage Befehl
git add DATEI
}}}

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

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
git push ADRESSE BRANCHNAME
}}}

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

{{{#!vorlage 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

{{{#!vorlage Befehl
git restore --staged <Datei>
}}}

um einzelne Dateien aus der Staging Area zu entfernen oder 

{{{#!vorlage Befehl
git restore --staged .
}}}

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

Alternativ

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
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`

{{{#!vorlage Befehl
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.

{{{#!vorlage Befehl
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:

{{{#!code bash
# 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:github/gitignore: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:

{{{#!vorlage Befehl
git branch
}}}

Zum Anzeigen von remote Branches gibt man ein:

{{{#!vorlage Befehl
git branch -r
}}}

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

{{{#!vorlage Befehl
git branch BRANCHNAME
}}}

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

{{{#!vorlage Befehl
git checkout BRANCHNAME
}}}


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

local:
{{{#!vorlage Befehl
git branch -d THE_LOCAL_BRANCH
}}}
remote:
{{{#!vorlage Befehl
git push origin :THE_REMOTE_BRANCH
}}}

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

{{{#!vorlage Befehl
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:

{{{#!vorlage Befehl
patch -p1 < PATCHDATEI.patch
}}}

= Grafische Oberflächen =
Es gibt eine Reihe von grafischen Oberflächen für Git. Diese sind im Übersichtsartikel [:Grafische Oberflächen für Git:] aufgeführt.

= Problembehebung =
== Git und Subversion ==
Sollte man gezwungen sein, mit einem [:Archiv/Subversion:Subversion]-Server zu arbeiten, kann man zur lokalen Verwaltung trotzdem Git einsetzen. Man muss nur das entsprechende Paket installieren:

{{{#!vorlage Paketinstallation
git-svn, universe
}}}

= Links =
== Intern ==
## * [:Archiv/Gitolite:] - Verwaltung eines Git-Servers
 * [:Versionsverwaltung:] {Übersicht} Übersichtsartikel

==Extern ==
 * [https://git-scm.com/ Projektseite] {en}
  * [https://www.kernel.org/pub/software/scm/git/docs/user-manual.html User Manual] {en} - offizielle Dokumentation
  * [http://gitref.org/ Git-Referenz] {en} - für den schnellen, aber dennoch umfangreichen Einstieg
  * [https://ndpsoftware.com/git-cheatsheet.html Cheatsheet] {en} - Kurzübersicht Git-Befehle
## 404, 11.07.2018, Beforge * [https://www.atlassian.com/de/git/tutorial Tutorial] {de} - von Atlassian
 * [http://gitbu.ch/ Das deutsche Git-Buch] {de} - umfassende Materialsammlung zum Erlernen und Lehren von Git
 * [https://git-scm.com/book/de Pro Git] {de} {en} {fr} {nl} {pt} {ru} {zh} {ja} {ko} - mehrsprachige Dokumentation von Scott Chacon, auch als Buch erhältlich
 * [https://svij.org/blog/2014/10/25/git-fur-einsteiger-teil-1/ Git für Einsteiger - Teil 1] {de} - Blogbeitrag, 10/2014
  * [https://svij.org/blog/2014/11/01/git-fur-einsteiger-teil-2/ Git für Einsteiger - Teil 2] {de} - Blogbeitrag, 11/2014
  * [https://svij.org/blog/2015/01/12/git-fur-einsteiger-teil-3/ Git für Einsteiger - Teil 3] {de} - Blogbeitrag, 01/2015
## Seite z. Z. nicht erreichbar, 11.07.2018, Beforge * [http://blog.fitzer.org/linux/git-einrichtung/ Git Einrichtung] {de} - Blogbeitrag zur Repository-Einrichtung auf Server und Client, 05/2009
 * [youtube:6EtNLRTkBAY:Gitlab Workshop CLT 2019] {de}
 * [http://www.freiesmagazin.de/mobil/freiesMagazin-2008-08-bilder.html#08_08_git Git Howto] {de} - freiesMagazin 08/2008
 * [github::GitHub] {en} - Git-Repositorien für Open-Source-Programme, GitHub Inc. seit 2018 zu Microsoft
 * [https://gitlab.org/ GitLab] {en} - Git-Repositorien für Open-Source-Programme
 * [youtube:4XpnKHJAok8:Linus Torvalds über Git] {en} 14.5.2007

# tag: Versionsverwaltung, Shell