1. Иш бошланиши
- 1.1 Талқинларни бошқариш ҳақида
- 1.2 Git нинг қисқача тарихи
- 1.3 Git асоси
- 1.4 Командалар сатри
- 1.5 Git ни ўрнатиш
- 1.6 Git да биринчи созлашлар
- 1.7 Қандай ёрдам олиш мумкин?
- 1.8 Хулосалар
2. Git асослари
3. Git да тармоқланиш
4. Git серверда
- 4.1 The Protocols
- 4.2 Getting Git on a Server
- 4.3 Sizning SSH ochiq (public) kalitingizni generatsiyalash
- 4.4 Setting Up the Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Third Party Hosted Options
- 4.10 Хулосалар
5. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Qism modullar (Submodule)
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
A1. Appendix A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Summary
A2. Appendix B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
A3. Appendix C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
7.4 Git Tools - Signing Your Work
Signing Your Work
Git is cryptographically secure, but it’s not foolproof. If you’re taking work from others on the internet and want to verify that commits are actually from a trusted source, Git has a few ways to sign and verify work using GPG.
First of all, if you want to sign anything you need to get GPG configured and your personal key installed.
$ gpg --list-keys /Users/schacon/.gnupg/pubring.gpg --------------------------------- pub 2048R/0A46826A 2014-06-04 uid Scott Chacon (Git signing key) <email@example.com> sub 2048R/874529A9 2014-06-04
If you don’t have a key installed, you can generate one with
Once you have a private key to sign with, you can configure Git to use it for signing things by setting the
user.signingkey config setting.
git config --global user.signingkey 0A46826A
Now Git will use your key by default to sign tags and commits if you want.
If you have a GPG private key setup, you can now use it to sign new tags.
All you have to do is use
-s instead of
$ git tag -s v1.5 -m 'my signed 1.5 tag' You need a passphrase to unlock the secret key for user: "Ben Straub <firstname.lastname@example.org>" 2048-bit RSA key, ID 800430EB, created 2014-05-04
If you run
git show on that tag, you can see your GPG signature attached to it:
$ git show v1.5 tag v1.5 Tagger: Ben Straub <email@example.com> 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 <firstname.lastname@example.org> Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number
To verify a signed tag, you use
git tag -v [tag-name].
This command uses GPG to verify the signature.
You need the signer’s public key in your keyring for this to work properly:
$ git tag -v v188.8.131.52 object 883653babd8ee7ea23e6a5c392bb739348b1eb61 type commit tag v184.108.40.206 tagger Junio C Hamano <email@example.com> 1158138501 -0700 GIT 220.127.116.11 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 <firstname.lastname@example.org>" gpg: aka "[jpeg image of size 1513]" Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A
If you don’t have the signer’s public key, you get something like this instead:
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 'v18.104.22.168'
In more recent versions of Git (v1.7.9 and above), you can now also sign individual commits.
If you’re interested in signing commits directly instead of just the tags, all you need to do is add a
-S to your
git commit command.
$ git commit -a -S -m 'signed commit' You need a passphrase to unlock the secret key for user: "Scott Chacon (Git signing key) <email@example.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
To see and verify these signatures, there is also a
--show-signature option to
$ 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) <firstname.lastname@example.org>" Author: Scott Chacon <email@example.com> Date: Wed Jun 4 19:49:17 2014 -0700 signed commit
Additionally, you can configure
git log to check any signatures it finds and list them in it’s output with the
$ git log --pretty="format:%h %G? %aN %s" 5c3386c G Scott Chacon signed commit ca82a6d N Scott Chacon changed the version number 085bb3b N Scott Chacon removed unnecessary test code a11bef0 N Scott Chacon first commit
Here we can see that only the latest commit is signed and valid and the previous commits are not.
In Git 1.8.3 and later, "git merge" and "git pull" can be told to inspect and reject when merging a commit that does not carry a trusted GPG signature with the
If you use this option when merging a branch and it contains commits that are not signed and valid, the merge will not work.
$ git merge --verify-signatures non-verify fatal: Commit ab06180 does not have a GPG signature.
If the merge contains only valid signed commits, the merge command will show you all the signatures it has checked and then move forward with the merge.
$ git merge --verify-signatures signed-branch Commit 13ad65e has a good GPG signature by Scott Chacon (Git signing key) <firstname.lastname@example.org> Updating 5c3386c..13ad65e Fast-forward README | 2 ++ 1 file changed, 2 insertions(+)
You can also use the
-S option with the
git merge command itself to sign the resulting merge commit itself. The following example both verifies that every commit in the branch to be merged is signed and furthermore signs the resulting merge commit.
$ git merge --verify-signatures -S signed-branch Commit 13ad65e has a good GPG signature by Scott Chacon (Git signing key) <email@example.com> You need a passphrase to unlock the secret key for user: "Scott Chacon (Git signing key) <firstname.lastname@example.org>" 2048-bit RSA key, ID 0A46826A, created 2014-06-04 Merge made by the 'recursive' strategy. README | 2 ++ 1 file changed, 2 insertions(+)
Everyone Must Sign
Signing tags and commits is great, but if you decide to use this in your normal workflow, you’ll have to make sure that everyone on your team understands how to do so. If you don’t, you’ll end up spending a lot of time helping people figure out how to rewrite their commits with signed versions. Make sure you understand GPG and the benefits of signing things before adopting this as part of your standard workflow.