-
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 Deine 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 VCS-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 deine 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 - Deine Arbeit signieren
Deine Arbeit signieren
Git ist kryptografisch sicher, aber nicht idiotensicher. Wenn du Arbeit von anderen im Internet übernehmen und überprüfen willst, dass diese 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 du etwas signieren willst, musst du zuerst GPG konfigurieren und deine 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 du noch keinen Schlüssel installiert hast, kannst du einen mit gpg --gen-key
generieren.
$ gpg --gen-key
Sobald du einen privaten Schlüssel zum Signieren hast, kannst du Git so konfigurieren, dass er zum Signieren verwendet wird, indem du die Konfigurationseinstellung user.signingkey
setzt.
$ git config --global user.signingkey 0A46826A!
Jetzt wird Git standardmäßig deinen Schlüssel benutzen, um Tags und Commits zu signieren, falls du es wünschst.
Tags signieren
Wenn du einen privaten GPG-Schlüssel eingerichtet hast, kannst du diesen nun zum Signieren neuer Tags verwenden.
Alles, was du tun musst, 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 du git show
auf dieses Tag ausführst, kannst du deine 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.
Du benötigst den öffentlichen Schlüssel des Unterzeichners in deinem 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 du den öffentlichen Schlüssel des Unterzeichners nicht hast, bekommst du 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) kannst du nun auch einzelne Commits signieren.
Wenn du daran interessiert bist, Commits direkt, anstatt nur die Tags zu signieren, musst du nur ein -S
zu deinem 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 das 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 kannst du 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 du diese Option verwendest, während du einen Branch mergst 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 dir der Merge-Befehl alle geprüften Signaturen an und fährt dann mit dem Merge 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(+)
Du kannst 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 du dich dazu entschieden hast, das in deinem normalen Arbeitsablauf zu verwenden, musst du sicherstellen, dass jeder in deinem Team weiß, wie das geht. Wenn du das nicht tust, wirst du am Ende viel Zeit damit verbringen, den Leuten zu helfen herauszufinden, wie sie ihre Commits mit signierten Versionen neu schreiben können. Stelle sicher, dass du GPG und die Vorteile des Signierens von Dingen verstehst, bevor du dies als Teil deines Standard-Workflows übernimmst.