-
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.4 Git Tools - Ihre Arbeit signieren
Ihre Arbeit signieren
Git ist kryptografisch sicher, aber nicht idiotensicher. Wenn Sie Arbeit von anderen im Internet übernehmen und überprüfen wollen, dass die Commits tatsächlich von einer vertrauenswürdigen Quelle stammen, gibt es in Git einige Möglichkeiten, die Arbeit mit GPG zu signieren und zu überprüfen.
Einführung in GPG
Wenn Sie etwas signieren wollen, müssen Sie zuerst GPG konfigurieren und Ihren persönlichen Schlüssel installieren.
$ gpg --list-keys
/Users/schacon/.gnupg/pubring.gpg
---------------------------------
pub 2048R/0A46826A 2014-06-04
uid Scott Chacon (Git signing key) <schacon@gmail.com>
sub 2048R/874529A9 2014-06-04
Wenn Sie noch keinen Schlüssel installiert haben, können Sie einen mit gpg --gen-key
generieren.
$ gpg --gen-key
Sobald Sie einen privaten Schlüssel zum Signieren haben, können Sie Git so konfigurieren, dass er zum Signieren verwendet wird, indem Sie die Konfigurationseinstellung user.signingkey
setzen.
$ git config --global user.signingkey 0A46826A!
Jetzt wird Git standardmäßig Ihren Schlüssel benutzen, um Tags und Commits zu signieren, falls Sie es wünschen.
Tags signieren
Wenn Sie einen privaten GPG-Schlüssel eingerichtet haben, können Sie diesen nun zum Signieren neuer Tags verwenden.
Alles, was Sie tun müssen, ist -s
statt -a
zu verwenden:
$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Ben Straub <ben@straub.cc>"
2048-bit RSA key, ID 800430EB, created 2014-05-04
Wenn Sie git show
auf dieses Tag laufen lassen, können Sie Ihre GPG-Signatur daran angehängt sehen:
$ git show v1.5
tag v1.5
Tagger: Ben Straub <ben@straub.cc>
Date: Sat May 3 20:29:41 2014 -0700
my signed 1.5 tag
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTZbQlAAoJEF0+sviABDDrZbQH/09PfE51KPVPlanr6q1v4/Ut
LQxfojUWiLQdg2ESJItkcuweYg+kc3HCyFejeDIBw9dpXt00rY26p05qrpnG+85b
hM1/PswpPLuBSr+oCIDj5GMC2r2iEKsfv2fJbNW8iWAXVLoWZRF8B0MfqX/YTMbm
ecorc4iXzQu7tupRihslbNkfvfciMnSDeSvzCpWAHl7h8Wj6hhqePmLm9lAYqnKp
8S5B/1SSQuEAjRZgI4IexpZoeKGVDptPHxLLS38fozsyi0QyDyzEgJxcJQVMXxVi
RUysgqjcpT8+iQM1PblGfHR4XAhuOqN5Fx06PSaFZhqvWFezJ28/CLyX5q+oIVk=
=EFTF
-----END PGP SIGNATURE-----
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
Change version numberr
Überprüfen der Tags
Um ein signiertes Tag zu prüfen, benutzt man git tag -v <tag-name>
.
Dieser Befehl verwendet GPG, um die Signatur zu verifizieren.
Sie benötigen den öffentlichen Schlüssel des Unterzeichners in Ihrem Schlüsselbund, damit das korrekt funktioniert:
$ git tag -v v1.4.2.1
object 883653babd8ee7ea23e6a5c392bb739348b1eb61
type commit
tag v1.4.2.1
tagger Junio C Hamano <junkio@cox.net> 1158138501 -0700
GIT 1.4.2.1
Minor fixes since 1.4.2, including git-mv and git-http with alternates.
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Good signature from "Junio C Hamano <junkio@cox.net>"
gpg: aka "[jpeg image of size 1513]"
Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
Wenn Sie den öffentlichen Schlüssel des Unterzeichners nicht haben, bekommen Sie stattdessen so etwas wie das hier zu sehen:
gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A
gpg: Can't check signature: public key not found
error: could not verify the tag 'v1.4.2.1'
Commits signieren
In neueren Versionen von Git (v1.7.9 und neuer) können Sie nun auch einzelne Commits signieren.
Wenn Sie daran interessiert sind, Commits direkt, anstatt nur die Tags zu signieren, müssen Sie nur ein -S
zu Ihrem git commit
Befehl hinzufügen.
$ git commit -a -S -m 'Signed commit'
You need a passphrase to unlock the secret key for
user: "Scott Chacon (Git signing key) <schacon@gmail.com>"
2048-bit RSA key, ID 0A46826A, created 2014-06-04
[master 5c3386c] Signed commit
4 files changed, 4 insertions(+), 24 deletions(-)
rewrite Rakefile (100%)
create mode 100644 lib/git.rb
Um diese Signaturen zu sehen und zu überprüfen, gibt es für git log
auch die Option --show-signature
.
$ git log --show-signature -1
commit 5c3386cf54bba0a33a32da706aa52bc0155503c2
gpg: Signature made Wed Jun 4 19:49:17 2014 PDT using RSA key ID 0A46826A
gpg: Good signature from "Scott Chacon (Git signing key) <schacon@gmail.com>"
Author: Scott Chacon <schacon@gmail.com>
Date: Wed Jun 4 19:49:17 2014 -0700
Signed commit
Zusätzlich können Sie git log
konfigurieren, um alle gefundenen Signaturen zu überprüfen und sie in seiner Ausgabe im %G?
Format aufzulisten.
$ git log --pretty="format:%h %G? %aN %s"
5c3386c G Scott Chacon Signed commit
ca82a6d N Scott Chacon Change the version number
085bb3b N Scott Chacon Remove unnecessary test code
a11bef0 N Scott Chacon Initial commit
Hier können wir feststellen, dass nur der letzte Commit signiert und gültig ist und die vorherigen Commits nicht.
In Git 1.8.3 und neuer können git merge
und git pull
beim Mergen angewiesen werden, einen Commit mit der Befehlsoption --verify-signatures
zu prüfen und zurückzuweisen, wenn dieser keine vertrauenswürdige GPG-Signatur trägt.
Wenn Sie diese Option verwenden, während Sie einen Branch verschmelzen und dieser Commits enthält, die nicht signiert und gültig sind, wird der Merge nicht ausgeführt.
$ git merge --verify-signatures non-verify
fatal: Commit ab06180 does not have a GPG signature.
Wenn der Vorgang nur gültige signierte Commits enthält, zeigt Ihnen der Merge-Befehl alle geprüften Signaturen an und fährt dann mit dem Verschmelzen fort.
$ git merge --verify-signatures signed-branch
Commit 13ad65e has a good GPG signature by Scott Chacon (Git signing key) <schacon@gmail.com>
Updating 5c3386c..13ad65e
Fast-forward
README | 2 ++
1 file changed, 2 insertions(+)
Sie können die Option -S
mit dem git merge
Befehl auch verwenden, um den resultierenden Merge-Commit selbst zu signieren.
Das folgende Beispiel verifiziert bei jedem Commit in dem zusammenzuführenden Branch, dass er signiert ist und signiert darüber hinaus den resultierenden Merge-Commit.
$ git merge --verify-signatures -S signed-branch
Commit 13ad65e has a good GPG signature by Scott Chacon (Git signing key) <schacon@gmail.com>
You need a passphrase to unlock the secret key for
user: "Scott Chacon (Git signing key) <schacon@gmail.com>"
2048-bit RSA key, ID 0A46826A, created 2014-06-04
Merge made by the 'recursive' strategy.
README | 2 ++
1 file changed, 2 insertions(+)
Jeder muss signieren
Das Signieren von Tags und Commits ist zwar ganz schön, aber wenn Sie sich dazu entschieden haben, das in Ihrem normalen Arbeitsablauf zu verwenden, müssen Sie sicherstellen, dass jeder in Ihrem Team weiß, wie das geht. Wenn Sie das nicht tun, werden Sie am Ende viel Zeit damit verbringen, den Leuten zu helfen, herauszufinden, wie sie ihre Commits mit signierten Versionen neu schreiben können. Stellen Sie sicher, dass Sie GPG und die Vorteile des Signierens von Dingen verstehen, bevor Sie dies als Teil Ihres Standard-Workflows übernehmen.