-
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
7.12 Git Tools - Bundling
Bundling
Wir haben zwar die üblichen Methoden zur Übertragung von Git-Daten über ein Netzwerk (HTTP, SSH usw.) behandelt, aber es gibt noch eine weitere Möglichkeit, die zwar nicht häufig verwendet wird, aber durchaus nützlich sein kann.
Git ist in der Lage, seine Daten in einer einzigen Datei zu „bündeln“.
Das kann in verschiedenen Situationen nützlich sein.
Vielleicht ist Ihr Netzwerk ausgefallen und Sie möchten Änderungen an Ihre Mitarbeitenden senden.
Vielleicht arbeiten Sie irgendwo außerhalb Ihres Unternehmens und haben aus Sicherheitsgründen keinen Zugang zum Firmen-Netzwerk.
Möglicherweise ist Ihre Wireless-/Ethernet-Karte einfach kaputt.
Oder Sie haben im Moment keinen Zugang zu einem gemeinsamen Server, Sie wollen jemandem Updates per E-Mail schicken und keine 40 Commits per format-patch
übertragen.
Hier kann die Funktion git bundle
behilflich sein.
Der Befehl bundle
packt alles, was normalerweise mit einem git push
Befehl über die Leitung geschoben wird, in eine Binärdatei, die Sie an jemanden per E-Mail oder auf einem Flash-Laufwerk schicken können, um es dann in ein anderes Repository zu entpacken.
Lassen Sie uns ein einfaches Beispiel anschauen. Angenommen, Sie haben ein Repository mit zwei Commits:
$ git log
commit 9a466c572fe88b195efd356c3f2bbeccdb504102
Author: Scott Chacon <schacon@gmail.com>
Date: Wed Mar 10 07:34:10 2010 -0800
Second commit
commit b1ec3248f39900d2a406049d762aa68e9641be25
Author: Scott Chacon <schacon@gmail.com>
Date: Wed Mar 10 07:34:01 2010 -0800
First commit
Wenn Sie dieses Repository an jemanden schicken wollen und Sie keinen Zugriff auf ein Repository haben, um es zu pushen, oder wenn Sie einfach keins einrichten wollen, können Sie es mit git bundle create
bündeln.
$ git bundle create repo.bundle HEAD master
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), 441 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
Sie haben jetzt eine Datei mit der Bezeichnung repo.bundle
, die alle Daten enthält, die benötigt werden, um den master
Branch des Repositorys neu zu erstellen.
Mit dem Kommando bundle
müssen Sie jede Referenz oder jeden spezifischen Bereich von Commits auflisten, die Sie einbeziehen möchten.
Wenn Sie beabsichtigen, diese Datei irgendwo anders zu klonen, sollten Sie HEAD als Referenz hinzufügen, wie wir es hier getan haben.
Sie können diese repo.bundle
Datei per E-Mail an eine andere Person schicken oder sie auf einem USB-Laufwerk speichern und übergeben.
Auf der anderen Seite nehmen wir an, dass Sie diese repo.bundle
Datei erhalten haben und an dem Projekt mitarbeiten wollen.
Sie können die Binärdatei in ein Verzeichnis klonen, ähnlich wie Sie es von einer URL aus tun würden.
$ git clone repo.bundle repo
Cloning into 'repo'...
...
$ cd repo
$ git log --oneline
9a466c5 Second commit
b1ec324 First commit
Wenn Sie HEAD nicht in die Verweise integrieren können, müssen Sie auch -b master
oder einen beliebigen anderen Branch angeben, da der Befehl sonst nicht weiß, welchen Branch er auschecken soll..
Nehmen wir an, Sie machen drei Commits darauf und wollen die neuen Commits über ein Bündel auf einem USB-Stick oder per E-Mail zurückschicken.
$ git log --oneline
71b84da Last commit - second repo
c99cf5b Fourth commit - second repo
7011d3d Third commit - second repo
9a466c5 Second commit
b1ec324 First commit
Zuerst müssen wir den Umfang der Commits bestimmen, die wir in das Bündel aufnehmen wollen. Im Gegensatz zu den Netzwerkprotokollen, die für uns den minimalen Datensatz für die Übertragung über das Netzwerk festlegen, müssen wir das hier manuell herausfinden. Jetzt könnten Sie einfach das Gleiche tun und das gesamte Repository bündeln. Das wird zwar funktionieren, aber es ist besser, nur die Differenz zu bündeln – einfach nur die drei Commits, die wir gerade lokal gemacht hatten.
Dazu müssen Sie die Differenz berechnen.
Wie wir in Commit-Bereiche beschrieben haben, können Sie den Umfang der Commits auf verschiedene Weise festlegen.
Um die drei Commits zu bestimmen, die wir in unserem master
Branch vorliegen haben und die nicht in dem Branch waren als wir ihn geklont haben, könnten wir zum Beispiel origin/master..master
oder master ^origin/master
benutzen.
Sie können die Ausführung mit dem Befehl log
überprüfen und testen.
$ git log --oneline master ^origin/master
71b84da Last commit - second repo
c99cf5b Fourth commit - second repo
7011d3d Third commit - second repo
Jetzt haben wir unsere Liste der Commits, die wir in das Bundle aufnehmen wollen, nun wollen wir sie bündeln.
Wir machen das mit dem Befehl git bundle create
, indem wir ihm einen Dateinamen zuweisen, der unser Bundle sein soll und den Umfang der Commits angeben, die wir aufnehmen wollen.
$ git bundle create commits.bundle master ^9a466c5
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (9/9), 775 bytes, done.
Total 9 (delta 0), reused 0 (delta 0)
Jetzt haben wir eine commits.bundle
Datei in unserem Verzeichnis.
Wenn wir diese Datei an unsere Partnerin schicken, kann sie diese in das originale Repository importieren, auch wenn dort zwischenzeitlich weitere Arbeiten stattgefunden haben.
Wenn sie das Bündel erhält, kann sie den Inhalt prüfen, bevor sie es in ihr Repository importiert.
Der erste Befehl ist der Befehl bundle verify
, der sicherstellt, dass die Datei tatsächlich ein gültiges Git-Bundle ist und dass diese alle notwendigen Vorgänger hat, um sie korrekt wiederherzustellen.
$ git bundle verify ../commits.bundle
The bundle contains 1 ref
71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
The bundle requires these 1 ref
9a466c572fe88b195efd356c3f2bbeccdb504102 second commit
../commits.bundle is okay
Hätte der Bündel-Ersteller nur die beiden letzten Commits gebündelt und nicht alle drei, wäre das ursprüngliche Repository nicht in der Lage, es zu importieren, da ihm der erforderliche Verlauf fehlt.
Das Kommando verify
hätte stattdessen so ausgesehen:
$ git bundle verify ../commits-bad.bundle
error: Repository lacks these prerequisite commits:
error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 Third commit - second repo
Unser erstes Bündel ist jedoch gültig, so dass wir daraus die Commits abrufen können (engl. fetch). Wenn Sie sehen möchten, welche Branches aus dem Bündel importiert werden können, gibt es auch einen Befehl, um nur die Kopfzeilen (engl. heads) aufzulisten:
$ git bundle list-heads ../commits.bundle
71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
Der Unterbefehl verify
wird Ihnen auch die Kopfzeilen anzeigen.
Es geht vielmehr darum, zu sehen, was man fetchen kann. Sie können dann die Befehle fetch
oder pull
verwenden, um Commits aus diesem Bündel zu importieren.
Hier holen wir den master
Branch aus dem Bündel in einen Branch mit dem Namen other-master
in unser Repository:
$ git fetch ../commits.bundle master:other-master
From ../commits.bundle
* [new branch] master -> other-master
Jetzt können wir sehen, dass wir die importierten Commits auf dem Branch other-master
haben, sowie alle Commits, die wir in der Zwischenzeit in unserem eigenen master
Branch gemacht haben.
$ git log --oneline --decorate --graph --all
* 8255d41 (HEAD, master) Third commit - first repo
| * 71b84da (other-master) Last commit - second repo
| * c99cf5b Fourth commit - second repo
| * 7011d3d Third commit - second repo
|/
* 9a466c5 Second commit
* b1ec324 First commit
Der Befehl git-bundle
kann also sehr nützlich sein, um gemeinsam netzwerkähnliche Operationen zu nutzen, wenn Sie nicht über das richtige Netzwerk oder ein gemeinsam genutztes Repository verfügen, um das Gleiche zu tun.