-
1. Erste Schritte
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Branches auf einen Blick
- 3.2 Einfaches Branching und Merging
- 3.3 Branch-Management
- 3.4 Branching-Workflows
- 3.5 Remote-Branches
- 3.6 Rebasing
- 3.7 Zusammenfassung
-
4. Git auf dem Server
- 4.1 Die Protokolle
- 4.2 Git auf einem Server einrichten
- 4.3 Erstellung eines SSH-Public-Keys
- 4.4 Einrichten des Servers
- 4.5 Git-Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Von Drittanbietern gehostete Optionen
- 4.10 Zusammenfassung
-
5. Verteiltes Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisions-Auswahl
- 7.2 Interaktives Stagen
- 7.3 Stashen und Bereinigen
- 7.4 Ihre Arbeit signieren
- 7.5 Suchen
- 7.6 Den Verlauf umschreiben
- 7.7 Reset entzaubert
- 7.8 Fortgeschrittenes Merging
- 7.9 Rerere
- 7.10 Debuggen mit Git
- 7.11 Submodule
- 7.12 Bundling
- 7.13 Replace (Ersetzen)
- 7.14 Anmeldeinformationen speichern
- 7.15 Zusammenfassung
-
8. Git einrichten
- 8.1 Git Konfiguration
- 8.2 Git-Attribute
- 8.3 Git Hooks
- 8.4 Beispiel für Git-forcierte Regeln
- 8.5 Zusammenfassung
-
9. Git und andere Systeme
- 9.1 Git als Client
- 9.2 Migration zu Git
- 9.3 Zusammenfassung
-
10. Git Interna
-
A1. Anhang A: Git in anderen Umgebungen
- A1.1 Grafische Schnittstellen
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Zusammenfassung
-
A2. Anhang B: Git in Ihre Anwendungen einbetten
- A2.1 Die Git-Kommandozeile
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Anhang C: Git Kommandos
- A3.1 Setup und Konfiguration
- A3.2 Projekte importieren und erstellen
- A3.3 Einfache Snapshot-Funktionen
- A3.4 Branching und Merging
- A3.5 Projekte gemeinsam nutzen und aktualisieren
- A3.6 Kontrollieren und Vergleichen
- A3.7 Debugging
- A3.8 Patchen bzw. Fehlerkorrektur
- A3.9 E-mails
- A3.10 Externe Systeme
- A3.11 Administration
- A3.12 Basisbefehle
3.3 Git Branching - Branch-Management
Branch-Management
Nachdem Sie nun einige Branches erzeugt, zusammengeführt und gelöscht haben, lassen Sie uns jetzt einige Werkzeuge für das Branch-Management betrachten, die sich als sehr nützlich erweisen werden, wenn Sie erst einmal Branches benutzen.
Der Befehl git branch
kann noch mehr, als Branches zu erzeugen und zu löschen.
Wenn Sie die Anweisung ohne Argumente ausführen, bekommen Sie eine einfache Auflistung Ihrer aktuellen Branches:
$ git branch
iss53
* master
testing
Beachten Sie das Sternchen (*
), das dem Branch master
vorangestellt ist: es zeigt an, welchen Branch Sie gegenwärtig ausgecheckt haben (bzw. den Branch, auf den HEAD
zeigt).
Wenn Sie zu diesem Zeitpunkt einen Commit durchführen, wird der Branch master
durch Ihre neue Änderung vorwärts bewegt.
Um sich den letzten Commit auf jedem Branch anzeigen zu lassen, können Sie die Anweisung git branch -v
ausführen:
$ git branch -v
iss53 93b412c Fix javascript issue
* master 7a98805 Merge branch 'iss53'
testing 782fd34 Add scott to the author list in the readme
Die nützlichen Optionen --merged
und --no-merged
können diese Liste nach Branches filtern, welche bereits mit dem Branch, auf dem Sie sich gegenwärtig befinden, zusammengeführt wurden und welche nicht.
Um zu sehen, welche Branches schon mit dem Branch zusammengeführt wurden, auf dem Sie gerade sind, können Sie die Anweisung git branch --merged
ausführen:
$ git branch --merged
iss53
* master
Da Sie den Branch iss53
schon früher gemergt haben, sehen Sie ihn in dieser Liste.
Branches auf dieser Liste ohne vorangestelltes *
können für gewöhnlich einfach mit der Anweisung git branch -d
gelöscht werden; Sie haben deren Änderungen bereits zu einem anderen Branch hinzugefügt, sodass Sie nichts verlieren würden.
Um alle Branches zu sehen, welche Änderungen enthalten, die Sie noch nicht integriert haben, können Sie die Anweisung git branch --no-merged
ausführen:
$ git branch --no-merged
testing
Das zeigt Ihnen einen anderen Branch.
Da er Änderungen enthält, die noch nicht integriert wurden, würde der Versuch, ihn mit git branch -d
zu löschen, fehlschlagen:
$ git branch -d testing
error: The branch 'testing' is not fully merged.
If you are sure you want to delete it, run 'git branch -D testing'.
Wenn Sie den Branch wirklich löschen und diese Bearbeitungen aufgeben wollen, können Sie dies mit der Option -D
erzwingen, worauf git in seinem Output hinweist.
Hinweis
|
Wenn Sie keinen Commit- oder Branch-Namen als Argument angeben, zeigen Ihnen die oben beschriebenen Optionen Sie können immer ein zusätzliches Argument angeben, um nach dem Merge-Status in Bezug auf einen anderen Zweig zu fragen, ohne zu diesen anderen Zweig zuerst wechseln zu müssen. So wie im Beispiel unten: „Was ist nicht in den Branch
|
Ändern eines Branchnamens
Achtung
|
Benennen Sie keine Branches um, die noch von anderen Mitarbeitern verwendet werden. Benennen Sie einen Branch wie master / main / mainline nicht um, ohne den Abschnitt „Ändern des Namens des Hauptzweigs“ gelesen zu haben. |
Angenommen, Sie haben einen Branch mit dem Namen bad-branch-name
und möchten ihn in corrected-branch-name
ändern, während die gesamte Historie beibehalten wird.
Sie möchten auch den Branchnamen auf der Remote-Repository ändern (GitHub, GitLab, anderer Server).
Wie machen Sie das?
Benennen Sie den Branch lokal mit dem Befehl git branch --move
um:
$ git branch --move bad-branch-name corrected-branch-name
Dies ersetzt Ihren Branch bad-branch-name
durch corrected-branch-name
, aber diese Änderung ist vorerst nur lokal.
Um den korrigierten Branchnamen für andere auf dem Remote-Repository sichtbar zu machen, pushen Sie ihn:
$ git push --set-upstream origin corrected-branch-name
Jetzt werfen wir einen kurzen Blick darauf, wo wir aktuell stehen:
$ git branch --all
* corrected-branch-name
main
remotes/origin/bad-branch-name
remotes/origin/corrected-branch-name
remotes/origin/main
Beachten Sie, dass Sie sich auf dem Branch corrected-branch-name
befinden und er ist auf dem Remote-Repository verfügbar.
Der fehlerhafte Branch ist ebenfalls auf dem Remote-Repository weiterhin vorhanden. Sie können ihn vom Remote-Repository folgendermaßen löschen:
$ git push origin --delete bad-branch-name
Nun ist der falsche Branchname vollständig durch den korrigierten Branchnamen ersetzt.
Ändern des Master Branch Namens
Warnung
|
Wenn Sie den Namen eines Branches wie master/main/mainline/default ändern, werden die Integrationen, Dienste, Hilfsprogramme und Build/Release-Skripte, die Ihr Repository verwendet, höchstwahrscheinlich nicht mehr funktionieren. Bevor Sie dies tun, sollten Sie dies gründlich mit Ihren Mitstreitern besprechen. Stellen Sie außerdem sicher, dass Sie Ihr Repo gründlich durchsuchen und alle Verweise auf den alten Branchnamen in Ihrem Code und in Ihren Skripten aktualisieren. |
Benennen Sie Ihren lokalen master
Branch mit dem folgenden Befehl in main
um
$ git branch --move master main
Es gibt lokal keinen master
Branch mehr, da er in main
Branch umbenannt wurde.
Damit andere den neuen main
Branch sehen können, müssen Sie ihn auf das Remote-Repository pushen.
Dadurch wird der umbenannte Branch auf dem Remote Repository verfügbar.
$ git push --set-upstream origin main
Jetzt haben wir folgenden Zustand:
$ git branch --all
* main
remotes/origin/HEAD -> origin/master
remotes/origin/main
remotes/origin/master
Ihr lokaler master
Branch ist weg, da er durch den main
Branch ersetzt wurde.
Der Branch main
ist nun auch auf dem Remote-Repository verfügbar.
Aber im Remote-Repository existiert immer noch eine master
Branch.
Andere Mitstreiter werden weiterhin den Branch master
als Grundlage für ihre Arbeit verwenden, bis Sie weitere Änderungen vornehmen.
Jetzt haben Sie noch ein paar Aufgaben vor sich, um den Übergang abzuschließen:
-
Alle Projekte, die von diesem abhängen, müssen ihren Code und/oder ihre Konfiguration aktualisieren.
-
Aktualisieren Sie alle Test-Runner Konfigurationsdateien.
-
Passen Sie Build- und Release-Skripte an.
-
Richten sie Umleitungen auf Ihrem Repo-Host für Dinge wie den Standardbranch des Repos, Merge-Regeln und andere Dinge ein, die mit Branchnamen übereinstimmen.
-
Aktualisieren Sie die Verweise auf den alten Branch in der Dokumentation.
-
Schließen oder Mergen sie alle Pull-Requests, die auf den alten Branch zeigen.
Nachdem Sie alle diese Aufgaben erledigt haben und sicher sind, dass der main
Branch genau wie der master
Branch ausgeführt wird, können Sie den master
Branch löschen:
$ git push origin --delete master