Einführung in Git

Inhaltsverzeichnis

Vorwort
1. Git konfigurieren
.... 1.1 Konfigurationsdateien
.... 1.2 Standardeinstellungen
.... 1.3 Aliase
2. Die Grundlagen von Git
.... 2.1 Repository erstellen
.... 2.2 Dateistatus
.... 2.3 Arbeiten mit dem Index
.... 2.4 Arbeiten mit Commits
.... 2.5 Verlauf anzeigen
.... 2.6 Arbeiten mit einem Remote-Repository
3. Verzweigung in Git
.... 3.1 Grundfunktionen
.... 3.2 Zweige zusammenführen
.... 3.3 Rerere
4. Zeiger in Git
.... 4.1 Zeiger verschieben
5. Empfohlene Lektüre

Vorwort

Git ist das beliebteste verteilte Versionskontrollsystem. [1] [2]

Der Hauptzweck von Git ist das Speichern von Schnappschüssen von sukzessive verbesserten Bedingungen Ihres Projekts (Pro git, 2019).

Dieser Artikel richtet sich an Personen, die mindestens über Grundkenntnisse und Fertigkeiten im Umgang mit Git verfügen und ihr Wissen erweitern möchten.

Hier werden nur technische Aspekte von git berücksichtigt. Um die Philosophie von git und seine interne Umsetzung genauer kennenzulernen, empfehle ich Ihnen, mehrere nützliche Bücher zu lesen (siehe Empfohlene Lektüre ).

1. Git konfigurieren

Bevor Sie mit git arbeiten, müssen Sie es selbst konfigurieren!

1.1 Konfigurationsdateien

• / etc / gitconfig - Allgemeine Einstellungen für alle Benutzer und Repositorys
• ~ / .gitconfig oder ~ / .config / git / config - Spezifische Benutzereinstellungen
• .git / config - Einstellungen für ein bestimmtes Repository

Es gibt ein spezielles Team

git config [<>] 

Dadurch können Sie bei Bedarf das Standardverhalten von git ändern, aber Sie können die Konfigurationsdateien manuell bearbeiten (ich denke so schneller).

Abhängig davon, welchen Parameter Sie an den Befehl git config (--system, --global, --local) übergeben, werden die Einstellungen in eine dieser Dateien geschrieben. Jede dieser „Ebenen“ (System, global, lokal) definiert die Werte der vorherigen Ebene neu!

Verwenden Sie git config --list --show-origin, um zu sehen, in welcher Datei welche Einstellungen installiert sind.

Dateien ignorieren
In git entscheiden Sie, welche Dateien in welches Commit aufgenommen werden sollen. Vielleicht möchten Sie jedoch, dass bestimmte Dateien niemals im Index und im Commit enthalten sind und nicht einmal in der nicht verfolgten Liste angezeigt werden. Dazu können Sie eine spezielle Datei (.gitignore) in Ihrem Repository erstellen und dort die Vorlage für ignorierte Dateien schreiben. Wenn Sie eine solche Datei nicht in jedem Repository erstellen möchten, können Sie sie global mit core.excludesfile definieren (siehe Nützliche Einstellungen ). Sie können auch die fertige Gitignore-Datei für die Programmiersprache herunterladen, an der Sie arbeiten.
Verwenden Sie zum Anpassen von .gitignore reguläre Bash-Ausdrücke .

1.2 Standardeinstellungen

Es gibt eine Reihe von Git-Einstellungen sowohl für den Server als auch für den Client. Hier werden nur grundlegende Client-Einstellungen berücksichtigt.

Verwenden Sie

 git config name value 

Dabei ist name der Name des Parameters und value der Wert, um die Einstellungen festzulegen.
Ein Beispiel:

 git config --global core.editor nano 

installiert den Standardeditor nano.

Sie können den Wert eines vorhandenen Parameters mit git config --get [name] anzeigen, wobei name der Parameter ist, dessen Wert Sie abrufen möchten.

Nützliche Einstellungen:

• user.name - Der Name, der beim Erstellen des Commits verwendet wird
• user.email - E-Mail, die beim Erstellen des Commits verwendet werden soll
• core.excludesfile - Eine Datei, deren Vorlage verwendet wird, um bestimmte Dateien global zu ignorieren
• core.editor - Der Standardeditor
• commit.template - Die Datei, deren Inhalt für die Standard-Commit-Nachricht verwendet wird (siehe Arbeiten mit Commits ).
• help.autocorrect - Wenn auf 1 gesetzt, führt git falsch geschriebene Befehle aus.
• credential.helper [mode] - Legt den Speichermodus für Anmeldeinformationen fest. [Cache] - Anmeldeinformationen werden für einen bestimmten Zeitraum gespeichert, Kennwörter werden nicht gespeichert (- Zeitüberschreitung [Sekunden] die Anzahl der Sekunden, nach denen die Daten gelöscht werden, standardmäßig 15 Minuten). [store] - Die Anmeldeinformationen werden unbegrenzt lange im Clear gespeichert (--file [file] gibt den Pfad zum Speichern von Daten an, standardmäßig ~ / .git-credentials).

1.3 Aliase

Wenn Sie nicht jeden Befehl für Git vollständig drucken möchten, können Sie problemlos Aliase konfigurieren. So erstellen Sie einen Alias:

 git config alias.SHORT_NAME COMMAND 

Dabei ist SHORT_NAME der Name, der abgekürzt werden soll, und COMMAND die Befehle, die abgekürzt werden sollen. Ein Beispiel:

 git config --global alias.last 'log -1 HEAD' 

Nachdem Sie diesen Befehl ausgeführt haben, können Sie Informationen zum letzten Commit für den aktuellen Zweig anzeigen, indem Sie git last ausführen.

Ich rate Ihnen, die folgenden Abkürzungen zu verwenden (Sie können auch eigene definieren):

• st = Status
• ch = Kasse
• br = Zweig
• mg = zusammenführen
• cm = Festschreiben
• reb = rebase
• lg = "git log --pretty = format: '% h -% ar:% s'"

Verwenden Sie zum Anzeigen der Konfigurationseinstellungen: git config --list.

2. Die Grundlagen von Git

Hier werden nur obligatorische und nützliche (meiner Meinung nach) Parameter aufgeführt, da die Auflistung aller unangemessen ist. Verwenden Sie dazu den git-Befehl -help oder --help, wobei command der Name des Befehls für die Hilfe ist, die Sie erhalten möchten.

2.1 Repository erstellen

• git init [<Optionen>] - Erstellt ein Git-Repository und ein .git-Verzeichnis im aktuellen Verzeichnis (oder in dem nach --separate-git-dir <git_root> angegebenen Verzeichnis. In diesem Fall befindet sich das .git-Verzeichnis an einer anderen Stelle).
• Git-Klon [<Optionen>] [-] <Repository> [<Ordner>] [-o, --origin <Name>] [-b, --Branch <branch>] [--single-branch] [- -no-tags] [--separate-git-dir <git_root>] [-c, --config <key = value>] - Klont Repositorys mit dem Namensursprung (oder dem von Ihnen angegebenen -o <Name>) ), in dem Zweig, auf den HEAD zeigt (oder dem, den Sie -b <branch> angeben). Sie können auch nur den erforderlichen HEAD-Zweig (oder den in -b <branch> angegebenen) klonen, indem Sie --single-branch angeben. Standardmäßig werden alle Tags geklont. Wenn Sie jedoch --no-tags angeben, können Sie sie nicht klonen. Nachdem der Befehl ausgeführt wurde, wird das .git-Verzeichnis im aktuellen Verzeichnis erstellt (oder in dem nach --separate-git-dir <git_root> angegebenen Verzeichnis. In diesem Fall befindet sich das .git-Verzeichnis an einer anderen Stelle).

2.2 Dateistatus

Verwenden Sie Folgendes, um den Status von Dateien in Ihrem Repository anzuzeigen:

 git status [<>] 

Dieser Befehl kann Ihnen zeigen: In welchem ​​Zweig Sie sich gerade befinden und welchen Status alle Dateien haben. Es sind keine Optionen erforderlich, nur -s können von den nützlichen unterschieden werden, die eine kurze Vorstellung vom Status der Dateien zeigen.

Datei-Lebenszyklus
Wie Sie auf dem Bild sehen können, können die Dateien nicht mehr verfolgt und verfolgt werden. Die überwachten Dateien können sich in drei Zuständen befinden: Nicht geändert (nicht geändert), geändert (geändert), vorbereitet (bereitgestellt).
Wenn Sie (mit git add) eine "Nicht überwachte" Datei hinzufügen, wird diese in den Status "Vorbereitet" versetzt.
Wenn Sie die Datei in den Status "Nicht geändert" ändern, wird sie in den Status "Geändert" versetzt. Wenn Sie die geänderte Datei speichern (dh im Status "Geändert"), wird sie in den Status "Vorbereitet" versetzt. Wenn Sie eine Datei festschreiben (dh im Status "Vorbereitet"), wird sie in den Status "Nicht geändert" versetzt.
Wenn sich die Versionen der Datei in HEAD und im Arbeitsverzeichnis unterscheiden, befindet sich die Datei im Status "Geändert". Andernfalls (wenn die Version im HEAD und im Arbeitsverzeichnis identisch ist) befindet sich die Datei im Status "Nicht geändert".
Wenn sich die Version der Datei in HEAD vom Arbeitsverzeichnis unterscheidet, sich jedoch nicht von der Version im Index unterscheidet, befindet sich die Datei im Status "Vorbereitet".

Dieser Zyklus kann wie folgt dargestellt werden:
Nicht geändert -> Geändert -> Bereitgestellt -> Nicht geändert
Das heißt, Sie ändern die Datei, speichern sie im Index, führen ein Commit durch und wiederholen den Vorgang.

2.3 Arbeiten mit dem Index

Ich hoffe, Sie verstehen, wie der Lebenszyklus des Git-Repositorys aussieht. Nun wollen wir sehen, wie Sie den Index und die Dateien in Ihrem Git-Repository verwalten können.

Ein Index ist eine Zwischenstelle zwischen Ihrem letzten und dem nächsten Commit. Sie können Dateien zum Index hinzufügen oder daraus entfernen. Beim Festschreiben werden Daten aus dem Index und nicht aus dem Arbeitsbereich abgerufen.

Verwenden Sie den Git-Status, um den Index anzuzeigen.

Verwenden Sie zum Hinzufügen von Dateien zum Index

 git add [<>] 

Nützliche git add Befehlsoptionen:

• -f, --force - fügt auch ignorierte Dateien hinzu
• -u, --update - aktualisierte Dateien aktualisieren

Um Dateien aus dem Index zu entfernen, können Sie die Befehle 2 git reset und git restore verwenden.
git-restore - Stellt funktionierende Baumdateien wieder her.
git-reset - setzt den aktuellen HEAD auf den angegebenen Status zurück.
Tatsächlich können Sie mit beiden Befehlen dasselbe erreichen.

Verwenden Sie Folgendes, um einige Dateien aus dem Index zu entfernen:

 git restore --staged <file> 

Auf diese Weise stellen Sie Ihren Index wieder her (oder löschen bestimmte Dateien aus dem Index), als ob git add seit dem letzten Commit nicht mehr für sie ausgeführt worden wäre. Mit diesem Befehl können Sie das Arbeitsverzeichnis wiederherstellen, sodass es so aussieht, als ob nach dem Festschreiben keine Änderungen vorgenommen wurden. Dieser Befehl hat jedoch ein etwas seltsames Verhalten: Wenn Sie dem Index eine neue Version Ihrer Datei hinzugefügt haben, können Sie Ihr Arbeitsverzeichnis erst ändern, wenn sich der Index von HEAD unterscheidet. Daher müssen Sie zuerst Ihren Index und erst dann das Arbeitsverzeichnis wiederherstellen. Leider ist dies nicht mit einem Befehl möglich, da beim Übergeben beider Argumente (git restore -SW) nichts passiert. Und trotzdem passiert nichts, wenn -W übergeben wird, wenn die Datei im Index und in HEAD unterschiedlich sind. Wahrscheinlich haben sie es zum Schutz getan, damit Sie Ihr Arbeitsverzeichnis nicht versehentlich ändern. Aber warum wird in diesem Fall das Argument -W standardmäßig übergeben? Im Allgemeinen verstehe ich nicht, warum dies getan wurde und warum dieser Befehl überhaupt hinzugefügt wurde. Für mich kommt das Zurücksetzen mit dieser Aufgabe viel besser zurecht, und es verfügt auch über eine umfassendere Funktionalität, da der Index und das Arbeitsverzeichnis nicht nur zum letzten Commit, sondern auch zu jedem anderen Commit verschoben werden können.

Die Entwickler selbst empfehlen jedoch die Verwendung von git restore -S, um den Index zurückzusetzen. Anstelle von Git Reset HEAD.

Mit dem Git-Status können Sie sehen, welche Dateien sich geändert haben. Wenn Sie jedoch auch wissen möchten, was sich genau in den Dateien geändert hat, verwenden Sie den folgenden Befehl:

 git diff [<options>] 

Wenn Sie den Befehl ohne Argumente ausführen, können Sie Ihren Index mit dem Arbeitsverzeichnis vergleichen. Wenn Sie dem Index bereits Dateien hinzugefügt haben, verwenden Sie git diff --cached, um die Unterschiede zwischen dem letzten Commit (oder dem von Ihnen angegebenen) und dem Arbeitsverzeichnis anzuzeigen. Sie können die Unterschiede zwischen zwei Commits oder Zweigen auch erkennen, indem Sie sie als Argument übergeben. Beispiel: git diff 00656c 3d5119 zeigt die Unterschiede zwischen Commit 00656c und 3d5119.

2.4 Arbeiten mit Commits

Jetzt, da sich Ihr Index im richtigen Zustand befindet, ist es Zeit, Ihre Änderungen festzuschreiben. Denken Sie daran, dass alle Dateien, für die Sie git add nach der Bearbeitung nicht ausgeführt haben, nicht in diesem Commit enthalten sind. In der Tat werden Dateien darin sein, aber nur ihre alte Version (falls vorhanden).

Verwenden Sie zum Festschreiben Ihrer Änderungen:

 git commit [<>] 

Nützliche Optionen für den Befehl git commit:

• -F, --file [Datei] - Schreiben Sie eine Festschreibungsnachricht aus der angegebenen Datei
• --author [author] - Ersetzen Sie den Commit-Autor
• --date [Datum] - Änderungsdatum ändern
• -m, --mesage [message] - Commit der Nachricht
• -a, --all - Übernehmen Sie alle Änderungen an Dateien
• -i, --include [files ...] - Fügt die angegebenen Dateien zum Index für das nächste Commit hinzu
• -o, --nur [Dateien ...] - Übernehmen Sie nur die angegebenen Dateien
• --amend - Vorheriges Commit überschreiben

Sie können eine Standard-Commit-Nachricht mit commit.template definieren. Diese Anweisung in der Konfigurationsdatei ist für die Datei verantwortlich, deren Inhalt für das Standard-Commit verwendet wird. Beispiel: git config --global commit.template ~ / .gitmessage.txt.

Sie können auch ein Commit ändern, löschen oder zusammenführen.
Wie Sie vielleicht bemerkt haben, können Sie das letzte Commit schnell mit git commit --amend überschreiben.
Verwenden Sie, um das Commit in Ihrer Story zu ändern

 git rebase -i <commit> 

Dabei ist Commit das oberste Commit in Ihrer Kette, von dem aus Sie etwas ändern möchten.

Wählen Sie nach dem Ausführen von git rebase -i im interaktiven Menü aus, was Sie tun möchten.

• Wählen Sie <commit> = Commit verwenden
• reword <commit> = Commit verwenden, aber die Commit-Nachricht ändern
• edit <commit> = Commit verwenden, aber aufhören zu reparieren
• squash <commit> = Commit verwenden, aber mit vorherigem Commit zusammenführen
• Fixup <commit> = als "Squash", aber überspringen Sie die Commit-Nachricht
• exec <Befehl> = Führen Sie den Befehl (Rest der Zeile) mithilfe der Shell aus
• break = hier anhalten (weiter mit "git rebase --continue")
• drop <commit> = Commit löschen
• label <label> = Geben Sie dem aktuellen HEAD einen Namen
• reset <label> = HEAD auf das angegebene Label zurücksetzen

So ändern Sie die Nachricht eines bestimmten Commits
Sie müssen die Auswahl ändern, um das Commit zu bearbeiten, das Sie ändern möchten.
Beispiel: Sie möchten die Festschreibungsnachricht 750f5ae ändern.

Wählen Sie 2748cb4 zuerst Commit
Bearbeiten Sie 750f5ae Sekunden Commit
Wählen Sie 716eb99 drittes Commit

Nach dem Speichern des Skripts kehren Sie zur Befehlszeile zurück und git teilt Ihnen mit, was als Nächstes zu tun ist:

Bei 750f5ae gestoppt ... zweites Commit
Sie können das Commit jetzt mit ändern

git commit --amend

Sobald Sie mit Ihren Änderungen zufrieden sind, führen Sie

Git Rebase - weiter

Wie oben angegeben, müssen Sie git commit --amend ausführen, um die Festschreibungsnachricht zu ändern. Führen Sie dann git rebase --continue aus. Wenn Sie mehrere Commits ausgewählt haben, um den Namen zu ändern, müssen diese Vorgänge für jedes Commit ausgeführt werden.

So löschen Sie ein Commit
Sie müssen die Zeile mit dem Commit löschen.
Beispiel: Sie möchten das Commit 750f5ae löschen
Sie müssen das Skript folgendermaßen ändern:
Wählen Sie 2748cb4 drittes Commit
Wählen Sie 750f5ae Sekunden Commit
Wählen Sie 716eb99 zuerst Commit
dazu:
Wählen Sie 2748cb4 zuerst Commit
Wählen Sie 716eb99 drittes Commit

Commits zusammenführen
Sie müssen die Auswahl ändern, um die Commits zu quetschen, die Sie zusammenführen möchten.
Beispiel: Sie möchten die Commits 750f5ae und 716eb99 kombinieren.
Sie müssen das Skript folgendermaßen ändern:
Wählen Sie 2748cb4 drittes Commit
Wählen Sie 750f5ae Sekunden Commit
Wählen Sie 716eb99 zuerst Commit
Auf solche
Wählen Sie 2748cb4 drittes Commit
Squash 750f5ae zweite Festschreibung
Squash 716eb99 zuerst festschreiben

Beachten Sie, dass Commits im interaktiven Skript in umgekehrter Reihenfolge als im Git-Protokoll angezeigt werden. Mit Squash kombinieren Sie das 750f5ae-Commit mit 716eb99 und das 750f5ae-Commit mit 2748cb4. Infolgedessen erhalten Sie ein Commit, das Änderungen an allen drei enthält.

2.5 Verlauf anzeigen

Befehl verwenden

 git log [<>] [<->] 

Sie können den Festschreibungsverlauf Ihres Repositorys anzeigen. Es gibt auch unzählige Optionen zum Sortieren und Suchen nach einem bestimmten Commit.

Nützliche Git Log Log Befehlsoptionen:

• -p - Zeigt den Unterschied für jedes Commit an.
• --stat - Zeigt Statistiken der geänderten Dateien für jedes Commit an.
• --graph - Zeigt ein ASCII-Diagramm mit Verzweigungen und Zusammenführungsverlauf an.

Sie können Commits auch nach Zeit, Menge usw. sortieren.

• - (n) Zeigt nur die letzten n Commits an.
• --since, --after - Zeigt Commits an, die nach dem angegebenen Datum getätigt wurden.
• - bis, - vor - Zeigt Commits an, die vor dem angegebenen Datum getätigt wurden.
• --author - Zeigt nur die Commits an, bei denen der Autoreneintrag mit der angegebenen Zeichenfolge übereinstimmt.
• --committer - Zeigt nur die Commits an, bei denen der Committer-Eintrag mit der angegebenen Zeichenfolge übereinstimmt.
• --grep - Zeigt nur Commits an, deren Nachricht die angegebene Zeichenfolge enthält.
• -S - Zeigt nur Commits an, bei denen eine Änderung des Codes zum Hinzufügen oder Entfernen der angegebenen Zeile geführt hat.

Hier einige Beispiele:
git log --since = 3.weeks - Zeigt Commits in den letzten 2 Wochen an
git log --since = "2019-01-14" - Zeigt die am 14.01.2019 vorgenommenen Commits an
git log --since = "Vor 2 Jahren 1 Tag" - Zeigt die Commits an, die vor 2 Jahren und einem Tag gemacht wurden.

Sie können auch das Ausgabeformat Ihrer Commits mit anpassen

 git log --format:["format"] 

Formatierungsoptionen für git log --format.

• % H - Commit Hash
• % h - Verkürzter Commit-Hash
• % T - Tree Hash
• % t - Verkürzter Baum-Hash
• % P - Eltern-Hash
• % p - Abgekürzter Eltern-Hash
• % an - Autorenname -% ae - Autor E-Mail
• % ad - Autorendatum (Datumsformat kann mit Option --date = Option eingestellt werden)
• % ar - Relatives Datum des Autors
• % cn - Name des Committers
• % ce - Committer-E-Mail
• % cd - Festschreibungsdatum
• % cr - Relatives Festschreibungsdatum
• % s - Inhalt

Ein Beispiel:

 git log --pretty=format:"%h - %ar : %s" 

zeigt eine Liste von Commits an, die aus einem Zeit-Hash und einer Commit-Nachricht besteht.

2.6 Arbeiten mit einem Remote-Repository

Da git eine verteilte Hartwährung ist, können Sie nicht nur mit lokalen, sondern auch mit externen Repositorys arbeiten.

Remote-Repositorys sind Versionen Ihres Projekts, die auf einem externen Server gespeichert sind.

Verwenden Sie zum Arbeiten mit externen Repositorys:

 git remote [<options>] 

Wenn Sie die Repositorys über die http-URL geklont haben, haben Sie bereits einen Link zu der externen. Andernfalls können Sie es mit hinzufügen

 git remote add [<options>] <name> <adres> 

Sie können die externen Zweige sofort mit -f, --fetch extrahieren (Sie erhalten die Namen und den Status der Zweige des externen Repositorys). Sie können Repositorys nur zum Senden oder Empfangen von Daten mit --mirror [= (push | fetch)] konfigurieren. Geben Sie --tags an, um Tags abzurufen.

Verwenden Sie zum Anzeigen verbundener externer Repositorys git remote ohne Argumente oder git remote -v, um die Adressen anzuzeigen, an die Daten aus dem Repository gesendet und empfangen werden sollen.

Verwenden Sie zum Verfolgen von Zweigen git branch -u <rep / br>, wobei rep der Name des Repositorys, br der Name des externen Zweigs und branch der Name des lokalen Zweigs ist. Oder git branch --set-upstream local_br origin / br, um anzugeben, welcher lokale Zweig den externen Zweig überwacht.

Wenn Ihre Niederlassung eine externe Niederlassung verfolgt, können Sie herausfinden, welche Niederlassung (lokal oder extern) hinter oder vor und wie viele Commits liegt. Wenn Sie beispielsweise nach einem Commit keinen Git-Push ausgeführt haben, liegt Ihr Zweig um 1 Commit vor dem äußeren. Sie können dies herausfinden, indem Sie git branch -vv ausführen. Führen Sie jedoch zuerst git fetch [remote-name] aus (--all, um Updates von allen Repositorys abzurufen), um die neuesten Daten aus einem externen Repository abzurufen. Verwenden Sie git branch --unset-upstream [<local_branch>], um die Zweigverfolgung abzubrechen.

Verwenden Sie git pull [rep] [branch], um Daten aus einem externen Repository herunterzuladen. Wenn Ihre Zweige extern verfolgen, können Sie sie beim Ausführen von Git Pull nicht angeben. Standardmäßig erhalten Sie Daten von allen überwachten Zweigen.

Verwenden Sie zum Hochladen von Zweigen in einen neuen Zweig git checkout -b <neuer_zweigname> <rep / branch>.

Verwenden Sie zum Senden von Daten an den Server

 git push [<rep>] [<br>] 

Dabei ist rep der Name des externen Repositorys und br der lokale Zweig, den Sie senden möchten. Sie können auch diesen Eintrag git push origin master verwenden: dev. Sie laden also Ihren lokalen Hauptzweig zum Ursprung hoch (dort heißt er jedoch dev). Sie können keine Daten an ein externes Repository senden, wenn Sie nicht dazu berechtigt sind. Außerdem können Sie keine Daten an einen externen Zweig senden, wenn dieser vor Ihrem liegt (im Allgemeinen können Sie ihn mit -f, --forse senden. In diesem Fall schreiben Sie den Verlauf im externen Repository neu). Sie können den Namen des Zweigs weglassen, wenn Ihr Zweig die Außenseite verfolgt.

Um externe Zweige zu löschen, verwenden Sie

 git push origin --delete branch_name 

Detaillierte Informationen zum externen Repository (Adressen zum Senden und Empfangen, wie von HEAD angegeben, externe Zweige, lokale Zweige, die für Git Pull konfiguriert sind, und lokale Links, die für Git Push konfiguriert sind)

 git remote show <remote_name> 

Verwenden Sie, um den Namen des externen Repositorys umzubenennen

 git remote rename <last_name> <new_name> 

Verwenden Sie zum Entfernen von Links zu einem externen Repository

 git remote rm <name> 

3. Verzweigung in Git

Die Verzweigung ist ein leistungsstarkes Tool und eine der Hauptfunktionen von git, da Sie damit schnell verschiedene Verzweigungen Ihres Repositorys erstellen und zwischen diesen wechseln können. Das Hauptkonzept der Verzweigung besteht darin, dass Sie von der Hauptentwicklungslinie abheben und unabhängig davon weiterarbeiten können, ohne die Hauptlinie zu beeinträchtigen. Ein Zweig zeigt immer auf das letzte Commit darin, und HEAD zeigt auf den aktuellen Zweig (siehe Zeiger in git ).

3.1 Grundfunktionen

Verwenden Sie zum Erstellen eines Zweigs

 git branch <branch_name> [<start_commit>] 

Hier ist branch_name der Name für den neuen Zweig, und start_commit ist das Commit, auf das der Zweig verweist (dh das letzte Commit darin). Standardmäßig befindet sich der Zweig beim letzten Commit des übergeordneten Zweigs.

Git-Verzweigungsoptionen:

• -r | -a [--merged | --no-fusioniert] - Liste der überwachten externen Zweige -r. -a. --merged. --no-merged.
• -l, -f <-> [<->] — -l. , -f. < >.
• -r (-d | -D) — -r. -d. ( ) -D.
• -m | -M [< >] < > — / (-m). / , -M.
• (- | -) [<->] <-> — -c. , -C.
• -v, -vv - Liste der Zweige mit dem letzten Commit für den Zweig -v. Liste und Status der überwachten Zweige mit dem letzten Commit für sie.

Weitere Informationen finden Sie unter git branch -h | --Hilfe.

Verwenden Sie git checkout, um zu einem Zweig zu wechseln. Sie können einen Zweig auch erstellen, indem Sie git checkout -b <branch> ausführen.

3.2 Zweige zusammenführen

Verwenden Sie Git Merge, um zwei Zweige eines Git-Repositorys zusammenzuführen.

Nützliche Optionen für das Zusammenführen von Git:

• --squash - Erstellen Sie ein Commit, anstatt es zusammenzuführen. Wenn Sie einen Konflikt in den Zweigen haben, fügen Sie nach dem Beheben des Konflikts 2 Commits zum Zweig hinzu (Commit aus dem zusammengeführten Zweig + Merge-Commit). Wenn Sie dieses Argument angeben, fügen Sie jedoch nur einen Commit hinzu (Merge-Commit).
• --ff-only - Nicht zusammenführen, wenn ein Konflikt vorliegt. Lassen Sie andere Konflikte lösen: D.
• -X [Strategie] - Verwenden Sie die ausgewählte Zusammenführungsstrategie.
• --abort - Abbrechen der Zusammenführung.

Der Fusionsprozess.
Wenn Sie keine neuen Commits für den übergeordneten Zweig ausgeführt haben, läuft die Zusammenführung auf schnellen Vorlauf hinaus, als ob Sie keinen neuen Zweig erstellen würden, und alle Änderungen wurden genau hier (im übergeordneten Zweig) vorgenommen.

Wenn Sie in beiden Zweigen Commits vorgenommen haben, aber keinen Konflikt erstellt haben, erfolgt die Zusammenführung in der „rekursiven Strategie“. Das heißt, Sie müssen nur ein Zusammenführungs-Commit erstellen, um die Änderungen zu übernehmen (verwenden Sie die Option --squash, um das Erstellen eines zusätzlichen Commits zu vermeiden.) .
Wenn Sie in beiden Zweigen Commits vorgenommen haben, die unterschiedliche Änderungen an demselben Teil derselben Datei vorgenommen haben, müssen Sie den Konflikt lösen und das Merge-Commit festschreiben.

Bei der Lösung des Konflikts müssen Sie auswählen, welchen Teil der Änderungen aus den beiden Zweigen Sie verlassen möchten. Wenn Sie eine in Konflikt stehende Datei öffnen, enthält diese Folgendes:
<<<<<<< HEAD
Es wird eine Version des letzten Commits des aktuellen Zweigs
angezeigt ======
Es wird eine Version des letzten Commits des zusammengeführten Zweigs
angezeigt >>>>>>> Hier der Name Zweige, mit denen wir zusammenführen

Nachdem Sie den Konflikt gelöst haben, müssen Sie die Zusammenführung durch Festschreiben abschließen.

Während eines Konflikts können Sie sehen, welche Unterschiede in welchen Dateien bestehen.
git diff --ours - Unterschied vor dem Zusammenführen und nach
git diff --theirs - Unterschied des zusammengeführten Zweigs vor dem Zusammenführen und nach dem Zusammenführen von
git diff --base - Unterschied zwischen beiden Zweigen vor und nach dem Zusammenführen

Wenn Sie das Zusammenführen nicht zulassen möchten, verwenden Sie verschiedene Zusammenführungsstrategien, indem Sie entweder "unsere" Version (dh die im aktuellen Zweig befindliche) oder die "ihre" Version im zusammengeführten Zweig auswählen, ohne den Konflikt zu korrigieren. Führen Sie git merge --Xours bzw. git merge --Xtheirs aus.

3.3 Erneut

Erneut - "Aufgezeichnete Lösung wiederverwenden" - "Gespeicherte Konfliktlösungen wiederverwenden". Der Wiederholungsmechanismus kann sich daran erinnern, wie Sie einen bestimmten Teil des Konflikts in der Vergangenheit gelöst haben, und den Konflikt beim nächsten Auftreten automatisch korrigieren.

Zum erneuten Aktivieren tun

 git config --global rerere.enabled true 

Sie können rerere auch aktivieren, indem Sie das Verzeichnis .git / rr-cache im gewünschten Repository erstellen.

Verwenden Sie den Status git rerere, um zu sehen, für welche Dateien rerere Snapshots gespeichert hat, bevor Sie sie zusammenführen.

Verwenden Sie git rerere diff, um den aktuellen Konfliktstatus anzuzeigen.

Wenn während des Zusammenführens Folgendes angezeigt wird: 'nameFile' wurde mit der vorherigen Auflösung aufgelöst. Daher hat rerere den Konflikt bereits mithilfe des Caches gelöst.

Um die automatische Konfliktlösung abzubrechen, verwenden Sie git checkout --conflict = merge, damit Sie die automatische Konfliktlösung abbrechen und die Datei (en) zur manuellen Lösung in den Konfliktstatus zurückversetzen.

4. Zeiger in Git

Git hat Zeiger wie HEAD Branch. Tatsächlich ist alles sehr einfach. HEAD zeigt auf den aktuellen Zweig und der Zweig zeigt auf das letzte Commit darin. Zum Verständnis ist es jedoch besser, sich vorzustellen, dass HEAD das letzte Commit angibt.

4.1 Zeiger verschieben

Das Pro-Git-Buch bietet ein sehr gutes Beispiel dafür, wie Sie Ihr Repository verwalten können. Ich werde mich also auch daran halten. Stellen Sie sich vor, Git verwaltet den Inhalt von drei verschiedenen Bäumen. Hier bezieht sich "Baum" auf einen "Satz von Dateien".
In seinen üblichen Operationen verwaltet Git drei Bäume:

• HEAD - Momentaufnahme des letzten Commits, übergeordnetes Element des nächsten
• Index - Momentaufnahme des nächsten bevorstehenden Commits
• Arbeitsverzeichnis - Sandbox

Tatsächlich bietet git Werkzeuge zum Manipulieren aller drei Bäume. Als nächstes wird der Befehl git reset erläutert, mit dem Sie mit drei Bäumen Ihres Repositorys arbeiten können.

Mit den verschiedenen Optionen dieses Befehls können Sie:

• --soft - Nur HEAD zurücksetzen
• --mixed - HEAD und Index zurücksetzen
• --hard - HEAD, Index und Arbeitsverzeichnis zurücksetzen

Durch Zurücksetzen wird zum angegebenen Commit gewechselt. Der Standardwert ist --mixed.

Beispiel 1. Sie haben 3 zusätzliche Festschreibungen vorgenommen, von denen jede kleine Änderungen mit sich bringt, und Sie möchten eine davon vornehmen. Sie können also mit git reset --soft den HEAD-Zeiger verschieben, während der Index und das Arbeitsverzeichnis unberührt bleiben und festgeschrieben werden. Infolgedessen sieht Ihre Geschichte so aus, als ob alle Änderungen in einem Commit vorgenommen wurden.

Beispiel 2. Sie haben dem Index zusätzliche Dateien hinzugefügt und möchten diese von dort entfernen. Hierfür können Sie git reset HEAD <files ...> verwenden. Oder möchten Sie, dass die Festschreibungsdateien wie ein paar Festschreibungen aussehen? Wie ich bereits sagte, können Sie den Index auf ein beliebiges Commit zurücksetzen, im Gegensatz zur Git-Wiederherstellung, die nur auf das letzte Commit zurückgesetzt wird. Nur mit der gemischten Option können Sie eine Aktion auf die angegebene Datei anwenden!

Beispiel 3. Sie haben begonnen, an einer neuen Funktion in Ihrem Projekt zu arbeiten, aber plötzlich sagt der Arbeitgeber, dass sie nicht mehr benötigt wird, und Sie sind wütend, wenn Sie den Git-Reset durchführen. Geben Sie Ihren Index, Ihre Dateien und Ihren HEAD zurück, wenn Sie noch nicht mit der Arbeit begonnen haben Funktionen. Und am nächsten Tag wird Ihnen gesagt, dass die Funktion noch heruntergespült werden sollte. Aber was tun? So bewegen Sie sich vorwärts, da Sie alle drei Bäume zurückgesetzt haben und sie jetzt mithilfe des Git-Protokolls nicht mehr im Verlauf finden können. Und es gibt eine Lösung - dies ist das Git-Reflog-Link-Protokoll. Mit diesem Befehl können Sie sehen, wohin HEAD zeigte, und es wird nicht nur den Commit-Verlauf nach unten, sondern auch nach oben verschoben. Dieses Protokoll ist für jeden Benutzer lokal.

Im Allgemeinen denke ich, dass Sie viel mehr Beispiele als ich finden können. Abschließend kann ich sagen, dass Sie mit git reset zaubern können ...

5.

1. Pro git — Scott Chacon
2. Git — . , ,
3. Git Essentials — F. Santacroce
4. Git: Version Control for Everyone (2013) — R. Somasundaram
5. Version Control with Git: Powerful tools and techniques for collaborative software development (2009) — J. Loeliger, M. McCullough
6. Practical Git and GitHub (2016) — D. Cruz
7. Git in Practice (2016) — M. McQuaid
8. Git Best Practices Guide (2014) — E. Pidoux
9. Learn Enough Git to Be Dangerous (2016) — M. Hartl
10. Learn Version Control with Git: A step-by-step course for the complete beginner (2014) — T. Günther
11. Git: Learn Version Control with Git: A step-by-step Ultimate beginners Guide (2017) — D. Hutten
12. Pragmatic Guide to Git (2010) — S. Travis
13. Git (2016) — .
14. A Hacker's Guide to Git (2014) — J. Wynn
15. Practical Git and GitHub (2016) — D. Cruz
16. Deploying to OpenShift(2018) — G. Dumpleton
17. Git for Teams (2015) — Emma Jane Hogbin Westby