Dokumentation für Einsteiger

Git-Tutorial: Teil 1, Teil 2.

Git Benutzerhandbuch. Alltag GIT mit 20 Befehlen oder so. Git-Workflows.

Fortgeschrittene Dokumentation

Git Magic, mit einer Reihe von Übersetzungen.

Pro Git. Das Buch über Git. Kaufen Sie es bei Amazon oder laden Sie es im PDF-, Mobi- oder ePub-Format herunter. Es gibt Übersetzungen in viele verschiedene Sprachen. Russische Übersetzung von GArik herunterladen.

Git Wiki.

Git Buch (Deutsch).

Offline-Dokumentation

Git hat integrierte Hilfe: führen Sie git help $THEMA aus. Führen Sie zum Beispiel git help git oder git help help aus.

Download und Installation

Unix-Benutzer: Herunterladen und installieren mit Ihrem Paketmanager.

Microsoft Windows: Laden Sie git-for-windows herunter.

MacOS X: Verwenden Sie Git, das mit XCode installiert wurde, oder laden Sie es von MacPorts oder git-osx-installer herunter, oder installieren Sie Git mit Homebrew: brew install git.

git-cola (Repository) ist eine Git GUI, die in Python und unter GPL-Lizenz geschrieben wurde. Linux, Windows, MacOS X.

TortoiseGit ist eine Windows Shell-Schnittstelle zu Git, die auf TortoiseSVN basiert; Open Source.

Erste Konfiguration

Dieser einfache Code erscheint oft in der Dokumentation, ist aber wichtig, daher wiederholen wir ihn hier. Git speichert Autor- und Committer-Namen/E-Mails in jedem Commit, also konfigurieren Sie Ihren echten Namen und Ihre bevorzugte E-Mail-Adresse.

$ git config --global user.name "User Name"
$ git config --global user.email user.name@example.org

Lokale und Remote-Tracking-Branches aktualisieren

Um Remote-Tracking-Branches zu aktualisieren, ohne lokale Branches zu aktualisieren, führen Sie git remote update [$REMOTE...] aus. Zum Beispiel:

$ git remote update
$ git remote update origin

$ git fetch $REMOTE $BRANCH

$ git fetch $REMOTE $BRANCH:$BRANCH

$ git pull $REMOTE $BRANCH

$ git fetch $REMOTE $BRANCH
$ git merge FETCH_HEAD

$ git fetch origin v1:v1  # Update v1
$ git pull --rebase origin master  # Update the current branch master
                                   # using rebase instead of merge
$ git merge v1

$ git checkout v1
$ git pull --rebase origin v1
$ git checkout master
$ git pull --rebase origin master
$ git merge v1

$ git pull origin

$ git pull

$ git push origin v1 master

$ git push origin v1:v1 master:master

$ git push origin

$ git push

$ git config push.default simple

$ git config push.default matching

$ git fetch origin tag $TAG1 tag $TAG2...

$ git fetch origin tag 1.4.2
$ git fetch origin v1:v1 tag 2.1.7

$ git push origin tag 1.4.2
$ git push origin v1 master tag 2.1.7

$ git push --tags origin

git checkout: Dateiinhalt wiederherstellen

git checkout kann zum Beispiel verwendet werden, um den Inhalt von Datei(en) auf den Stand eines Commits zurückzusetzen. So:

git checkout HEAD~ README

Die Befehle stellen den Inhalt der Datei README auf den vorletzten Commit im aktuellen Branch wieder her. Standardmäßig ist die Commit-ID einfach HEAD; d.h. git checkout README stellt README auf den letzten Commit wieder her.

(Verwenden Sie git checkout nicht, um den Inhalt einer Datei in einem Commit anzuzeigen, verwenden Sie git cat-file -p; z.B. git cat-file -p HEAD~:path/to/README).

git reset: (noch nicht gepushte) Commits entfernen

git reset verschiebt den Kopf des aktuellen Branches. Der Kopf kann auf jeden Commit verschoben werden, wird aber oft verwendet, um einen Commit oder einige (vorzugsweise nicht gepushte) Commits vom oberen Ende des Branches zu entfernen - das heißt, den Branch zurückzubewegen, um einige (nicht gepushte) Commits rückgängig zu machen.

git reset hat drei Betriebsmodi: soft, hard und mixed. Standard ist mixed. ProGit erklärt den Unterschied sehr klar. Bare-Repositories haben keine Indizes oder Arbeitsbäume, daher ist in einem Bare-Repo nur ein Soft-Reset möglich.

git reflog: Referenzprotokoll

Commits mit git reset zu entfernen oder den Kopf eines Branches zu verschieben, klingt gefährlich und ist es auch. Aber es gibt eine Möglichkeit, dies rückgängig zu machen: ein weiterer Reset zurück zum ursprünglichen Commit. Git entfernt Commits nicht sofort; nicht referenzierte Commits (in Git-Terminologie "dangling commits" genannt) bleiben für eine gewisse Zeit in der Datenbank (standardmäßig zwei Wochen), sodass Sie dorthin zurücksetzen oder einen neuen Branch erstellen können, der auf den ursprünglichen Commit zeigt.

Für jede Bewegung des Kopfes eines Branches - mit git commit, git checkout, git fetch, git pull, git rebase, git reset und so weiter - speichert Git ein Referenzprotokoll (kurz reflog). Für jede Bewegung speichert Git, wo der Kopf war. Der Befehl git reflog kann verwendet werden, um das Protokoll anzuzeigen (und zu manipulieren).

Zusätzlich zu den Verschiebungen des Kopfes jedes Branches speichert Git die Verschiebungen von HEAD - einer symbolischen Referenz, die (normalerweise) den aktuellen Branch benennt. HEAD wird mit git checkout $BRANCH geändert.

Standardmäßig zeigt git reflog die Verschiebungen von HEAD an, d.h. der Befehl ist äquivalent zu git reflog HEAD. Um die Verschiebungen des Kopfes eines Branches anzuzeigen, verwenden Sie den Befehl git reflog $BRANCH.

Um also einen git reset rückgängig zu machen, suchen Sie den ursprünglichen Commit in git reflog, verifizieren Sie ihn mit git show oder git log und führen Sie git reset $COMMIT_ID aus. Git speichert die Bewegung des Branch-Kopfes im Reflog, sodass Sie dieses Rückgängigmachen später wieder rückgängig machen können.

In einer komplexeren Situation möchten Sie einige Commits verschieben und gleichzeitig den Kopf des Branches zurücksetzen. Cherry-Picken Sie sie auf den neuen Branch. Wenn Sie zum Beispiel den Branch master auf den ursprünglichen Commit zurücksetzen, aber zwei Commits beibehalten möchten, die im aktuellen Branch erstellt wurden, tun Sie etwas wie:

$ git branch save-master  # create a new branch saving master
$ git reflog  # find the original place of master
$ git reset $COMMIT_ID
$ git cherry-pick save-master~ save-master
$ git branch -D save-master  # remove temporary branch

git revert: Commit rückgängig machen

git revert macht einen oder mehrere Commits rückgängig, d.h. er erstellt einen oder mehrere neue Commits, die die Auswirkungen der angegebenen Commits rückgängig machen. Es ist die einzige Möglichkeit, veröffentlichte Commits rückgängig zu machen ( git commit --amend, git rebase und git reset ändern den Branch auf Nicht-Fast-Forward-Weise, daher sollten sie nur für nicht gepushte Commits verwendet werden.)

Es gibt ein Problem beim Rückgängigmachen eines Merge-Commits. git revert kann den Code, der durch den Merge-Commit erstellt wurde, rückgängig machen, aber es kann nicht die Tatsache des Merges rückgängig machen. Siehe die Diskussion Wie man einen fehlerhaften Merge rückgängig macht.

Eine Sache, die nicht rückgängig gemacht werden kann

Was auch immer Sie rückgängig machen, es gibt eine Sache, die nicht rückgängig gemacht werden kann: überschriebene uncommittete Änderungen. Uncommittete Änderungen gehören nicht zu Git, daher kann Git nicht helfen, sie zu erhalten.

Die meiste Zeit warnt Sie Git, wenn Sie einen Befehl ausführen möchten, der uncommittete Änderungen überschreibt. Git erlaubt Ihnen nicht, Branches mit git checkout zu wechseln. Es hält Sie auf, wenn Sie mit einem nicht sauberen Arbeitsbaum rebachen wollen. Es weigert sich, neue Commits über nicht committete Dateien zu pullen.

Aber es gibt Befehle, die genau das tun - Dateien im Arbeitsbaum überschreiben. Befehle wie git checkout $PFADE oder git reset --hard überschreiben stillschweigend Dateien, einschließlich Ihrer uncommitteten Änderungen.

Mit diesem Wissen können Sie die Haltung "früh committen, oft committen" verstehen. Committen Sie so oft wie möglich. Committen Sie bei jeder Speicherung in Ihrem Editor oder IDE. Sie können Ihre Commits vor dem Pushen bearbeiten - Commit-Nachrichten ändern, Commits ändern, neu ordnen, kombinieren, aufteilen, entfernen. Aber speichern Sie Ihre Änderungen in der Git-Datenbank, entweder committen Sie die Änderungen oder stashen Sie sie zumindest mit git stash.

Zeilenenden

Git verfügt über integrierte Mechanismen zur Behandlung von Zeilenenden zwischen Plattformen mit unterschiedlichen End-of-Line-Stilen. Um Git die CRLF-Konvertierung zu ermöglichen, weisen Sie Dateien, die .gitattributes verwenden, das Attribut text zu. Für Dateien, die bestimmte Zeilenenden haben müssen, weisen Sie das Attribut eol zu. Für Binärdateien ist das Attribut natürlich binary.

Zum Beispiel:

$ cat .gitattributes
*.py text
*.txt text
*.png binary
/readme.txt eol=CRLF

Um zu überprüfen, welche Attribute Git für Dateien verwendet, verwenden Sie den Befehl git check-attr. Zum Beispiel:

$ git check-attr -a -- \*.py

Nützliche Hilfsmittel

GitAlias (Repository) ist eine große Sammlung von Aliases. Eine sorgfältige Auswahl von Aliases für häufig verwendete Befehle könnte Ihnen viele Tastatureingaben ersparen!

GitIgnore und https://github.com/github/gitignore sind Sammlungen von .gitignore-Dateien für alle Arten von IDEs und Programmiersprachen. Python inbegriffen!

pre-commit (Repositories) ist ein Framework zur Verwaltung und Wartung von Multi-Language Pre-Commit-Hooks. Das Framework ist in Python geschrieben und verfügt über viele Plugins für viele Programmiersprachen.

Staging-Bereich

Der Staging-Bereich, auch Index oder Cache genannt, ist ein Unterscheidungsmerkmal von Git. Der Staging-Bereich ist der Ort, an dem Git Patches sammelt, bevor er sie committet. Die Trennung zwischen dem Sammeln von Patches und der Commit-Phase bietet eine sehr nützliche Funktion von Git: Sie können die gesammelten Patches vor dem Commit überprüfen und sogar bearbeiten - einige Hunks entfernen, neue Hunks hinzufügen und erneut überprüfen.

Um Dateien zum Index hinzuzufügen, verwenden Sie git add. Das Sammeln von Patches vor dem Committen bedeutet, dass Sie dies für jede Änderung tun müssen, nicht nur zum Hinzufügen neuer (nicht getrackter) Dateien. Um das Committen zu vereinfachen, wenn Sie einfach alles ohne Überprüfung committen möchten, führen Sie git commit --all (oder einfach -a) aus - der Befehl fügt jede geänderte getrackte Datei zum Index hinzu und committet dann. Um eine oder mehrere Dateien unabhängig von den im Index gesammelten Patches zu committen, führen Sie git commit [--only|-o] -- $DATEI... aus.

Um Hunks von Patches zum Index hinzuzufügen, verwenden Sie git add --patch (oder einfach -p). Um gesammelte Dateien aus dem Index zu entfernen, verwenden Sie git reset HEAD -- $DATEI.... Um gesammelte Hunks hinzuzufügen/zu inspizieren/zu entfernen, verwenden Sie git add --interactive (-i).

Um die Unterschiede zwischen dem Index und dem letzten Commit (d.h. gesammelte Patches) anzuzeigen, verwenden Sie git diff --cached. Um die Unterschiede zwischen dem Arbeitsbaum und dem Index (d.h. gesammelte Patches) anzuzeigen, verwenden Sie einfach git diff. Um die Unterschiede zwischen dem Arbeitsbaum und dem letzten Commit (d.h. sowohl gesammelte als auch ungesammelte Patches) anzuzeigen, führen Sie git diff HEAD aus.

Siehe WhatIsTheIndex und IndexCommandQuickref im Git Wiki.

Root

Git wechselt in das Stammverzeichnis (oberstes Verzeichnis des Projekts, in dem sich das Unterverzeichnis .git befindet), bevor es einen Befehl ausführt. Git merkt sich jedoch das Verzeichnis, das vor dem Wechsel aktuell war. Einige Programme berücksichtigen das aktuelle Verzeichnis. Z.B. zeigt git status Dateipfade von geänderten und unbekannten Dateien relativ zum aktuellen Verzeichnis an; git grep sucht unter dem aktuellen Verzeichnis; git apply wendet nur die Hunks aus dem Patch an, die Dateien unter dem aktuellen Verzeichnis berühren.

Aber die meisten Befehle werden vom Stammverzeichnis aus ausgeführt und ignorieren das aktuelle Verzeichnis. Stellen Sie sich zum Beispiel vor, Sie haben zwei Arbeitsbäume, einen für den Branch v1 und den anderen für master. Wenn Sie v1 aus einem Unterverzeichnis innerhalb des zweiten Arbeitsbaums mergen möchten, müssen Sie Befehle so schreiben, als wären Sie im obersten Verzeichnis. Nehmen wir zum Beispiel zwei Arbeitsbäume, projekt-v1 und projekt:

$ cd project/subdirectory
$ git fetch ../project-v1 v1:v1
$ git merge v1

Beachten Sie den Pfad in git fetch ../project-v1 v1:v1: ../project-v1 und nicht ../../project-v1, obwohl wir die Befehle von einem Unterverzeichnis aus ausführen und nicht vom Stammverzeichnis aus.

ReReRe

Rerere ist ein Mechanismus, der hilft, wiederkehrende Merge-Konflikte zu lösen. Die häufigste Ursache für wiederkehrende Merge-Konflikte sind Topic-Branches, die in den Mainline gemerged und dann die Merge-Commits entfernt werden; dies wird oft durchgeführt, um die Topic-Branches zu testen und Rerere zu trainieren; Merge-Commits werden entfernt, um eine saubere lineare Historie zu haben und den Topic-Branch mit nur einem letzten Merge-Commit abzuschließen.

Rerere funktioniert, indem es die Zustände des Baums vor und nach einem erfolgreichen Commit speichert. Auf diese Weise kann Rerere Konflikte automatisch lösen, wenn sie in denselben Dateien auftreten.

Rerere kann manuell mit dem Befehl git rerere verwendet werden, wird aber meistens automatisch eingesetzt. Aktivieren Sie rerere mit diesen Befehlen in einem Arbeitsverzeichnis.

$ git config rerere.enabled true
$ git config rerere.autoupdate true

Sie müssen rerere nicht global aktivieren – Sie wollen rerere nicht in Bare-Repositories oder Single-Branch-Repositories; Sie benötigen rerere nur in Repositories, in denen Sie häufig Merges durchführen und Merge-Konflikte lösen.

Siehe Rerere im Buch.

Datenbankwartung

Die Git-Objektdatenbank und andere Dateien/Verzeichnisse unter .git erfordern periodische Wartung und Bereinigung. Beispielsweise hinterlässt das Bearbeiten von Commits unreferenzierte Objekte (im Git-Jargon „dangling objects“) und diese Objekte sollten bereinigt werden, um die Ansammlung von unnötigem Ballast in der Datenbank zu vermeiden. Der Befehl git gc wird für die Wartung verwendet. Git führt automatisch git gc --auto als Teil einiger Befehle aus, um schnelle Wartungsarbeiten durchzuführen. Benutzern wird empfohlen, von Zeit zu Zeit git gc --aggressive auszuführen; git help gc empfiehlt, es alle paar hundert Commits auszuführen; für intensivere Projekte sollte dies etwa einmal pro Woche erfolgen und für weniger aktive Projekte seltener (zweiwöchentlich oder monatlich).

git gc --aggressive entfernt nicht nur unreferenzierte Objekte, sondern packt auch die Objektdatenbank in indizierte und besser optimierte Packs; es packt auch symbolische Referenzen (Branches und Tags). Eine andere Möglichkeit, dies zu tun, ist die Ausführung von git repack.

Es gibt eine bekannte Nachricht von Linus Torvalds bezüglich der „Dummheit“ von git gc --aggressive. Die Nachricht kann jetzt sicher ignoriert werden. Sie ist alt und veraltet, git gc --aggressive ist seitdem viel besser geworden.

Für diejenigen, die git repack immer noch git gc --aggressive vorziehen, sind die empfohlenen Parameter git repack -a -d -f --depth=20 --window=250. Lesen Sie dieses detaillierte Experiment für eine Erklärung der Auswirkungen dieser Parameter.

Führen Sie von Zeit zu Zeit git fsck [--strict] aus, um die Integrität der Datenbank zu überprüfen. git fsck kann eine Liste von unreferenzierten Objekten ausgeben; das ist kein Fehler, sondern nur eine Erinnerung daran, regelmäßige Wartung durchzuführen.

Kommandozeilenoptionen und Argumente

git help cli empfiehlt, kurze Optionen/Flags nicht zu kombinieren. Meistens funktioniert die Kombination: git commit -av funktioniert einwandfrei, aber es gibt Situationen, in denen dies nicht der Fall ist. Z.B. kann git log -p -5 nicht als git log -p5 kombiniert werden.

Einige Optionen haben Argumente, einige sogar Standardargumente. In diesem Fall muss das Argument für eine solche Option zusammenhängend angegeben werden: -Oarg, niemals -O arg, denn für eine Option mit einem Standardargument bedeutet letzteres „Standardwert für Option -O verwenden und arg weiter an den Optionsparser übergeben“. Zum Beispiel hat git grep die Option -O, die eine Liste von Namen der gefundenen Dateien an ein Programm übergibt; das Standardprogramm für -O ist ein Pager (normalerweise less), aber Sie können Ihren Editor verwenden.

$ git grep -Ovim  # but not -O vim

Übrigens, wenn Git angewiesen wird, less als Pager zu verwenden (d.h. wenn der Pager in Git gar nicht konfiguriert ist, verwendet es standardmäßig less, oder wenn es less über die Umgebungsvariablen GIT_PAGER oder PAGER erhält, oder wenn es mit git config [--global] core.pager less konfiguriert wurde, oder wenn less im Befehl git grep -Oless verwendet wird), übergibt git grep die Option +/$pattern an less, was sehr praktisch ist. Leider übergibt git grep das Muster nicht, wenn der Pager nicht exakt less ist, selbst wenn es less mit Parametern ist (etwas wie git config [--global] core.pager less -FRSXgimq); glücklicherweise übergibt git grep -Oless immer das Muster.

bash/zsh-Vervollständigung

Es ist etwas mühsam, git rebase --interactive --preserve-merges HEAD~5 manuell einzugeben, selbst für diejenigen, die gerne die Kommandozeile benutzen, und hier leistet die Shell-Vervollständigung große Hilfe. Bash/zsh verfügen über programmierbare Vervollständigung, die oft automatisch installiert und aktiviert wird. Wenn Sie also Bash/zsh und Git installiert haben, sind Sie wahrscheinlich bereits fertig – gehen Sie einfach hin und verwenden Sie es auf der Kommandozeile.

Wenn Sie die erforderlichen Komponenten nicht installiert haben, installieren und aktivieren Sie das Paket bash_completion. Wenn Sie Ihre Git-Vervollständigung auf die neueste und beste Version aktualisieren möchten, laden Sie die erforderliche Datei von git contrib herunter.

Git-for-windows wird mit git-bash geliefert, für das bash completion installiert und aktiviert ist.

bash/zsh-Prompt

Für Liebhaber der Kommandozeile kann die Shell-Eingabeaufforderung viele nützliche Informationen enthalten. Um Git-Informationen in die Eingabeaufforderung aufzunehmen, verwenden Sie git-prompt.sh. Lesen Sie die detaillierten Anweisungen in der Datei.

Suchen Sie im Internet nach „git prompt“, um andere Eingabeaufforderungsvarianten zu finden.

SSH-Verbindungsfreigabe

SSH-Verbindungsfreigabe ist eine Funktion von OpenSSH und vielleicht Ablegern wie PuTTY. SSH-Verbindungsfreigabe ist eine Methode, um die Startzeit des SSH-Clients zu verkürzen, indem eine Verbindung aufgebaut und diese für alle nachfolgenden Clients wiederverwendet wird, die sich mit demselben Server verbinden. SSH-Verbindungsfreigabe kann verwendet werden, um viele kurze SSH-Sitzungen wie scp, sftp, rsync und natürlich Git über SSH zu beschleunigen. Wenn Sie regelmäßig von/zu Remote-Repositories fetchen/pullen/pushen, die über SSH zugänglich sind, wird die Verwendung der SSH-Verbindungsfreigabe empfohlen.

Um die SSH-Verbindungsfreigabe zu aktivieren, fügen Sie etwas wie folgt zu Ihrer ~/.ssh/config hinzu.

Host *
ControlMaster auto
ControlPath ~/.ssh/mux-%r@%h:%p
ControlPersist 600

Siehe OpenSSH wikibook und Suche für weitere Informationen.

SSH-Verbindungsfreigabe kann für GitHub, GitLab und SourceForge-Repositories verwendet werden, aber bitte beachten Sie, dass BitBucket dies nicht erlaubt und die Master-Verbindung nach kurzer Inaktivität zwangsweise schließt, sodass Sie Fehler wie diesen von SSH sehen werden: „Connection to bitbucket.org closed by remote host.“