-
1. Начало
- 1.1 За Version Control системите
- 1.2 Кратка история на Git
- 1.3 Какво е Git
- 1.4 Конзолата на Git
- 1.5 Инсталиране на Git
- 1.6 Първоначална настройка на Git
- 1.7 Помощна информация в Git
- 1.8 Обобщение
-
2. Основи на Git
-
3. Клонове в Git
-
4. GitHub
-
5. Git инструменти
- 5.1 Избор на къмити
- 5.2 Интерактивно индексиране
- 5.3 Stashing и Cleaning
- 5.4 Подписване на вашата работа
- 5.5 Търсене
- 5.6 Манипулация на историята
- 5.7 Мистерията на командата Reset
- 5.8 Сливане за напреднали
- 5.9 Rerere
- 5.10 Дебъгване с Git
- 5.11 Подмодули
- 5.12 Пакети в Git (Bundling)
- 5.13 Заместване
- 5.14 Credential Storage система
- 5.15 Обобщение
-
6. Настройване на Git
- 6.1 Git конфигурации
- 6.2 Git атрибути
- 6.3 Git Hooks
- 6.4 Примерна Git-Enforced политика
- 6.5 Обобщение
-
7. Git и други системи
- 7.1 Git като клиент
- 7.2 Миграция към Git
- 7.3 Обобщение
-
8. Git на ниско ниво
- 8.1 Plumbing и Porcelain команди
- 8.2 Git обекти
- 8.3 Git референции
- 8.4 Packfiles
- 8.5 Refspec спецификации
- 8.6 Транспортни протоколи
- 8.7 Поддръжка и възстановяване на данни
- 8.8 Environment променливи
- 8.9 Обобщение
-
9. Приложение A: Git в други среди
-
10. Приложение B: Вграждане на Git в приложения
- 10.1 Git от команден ред
- 10.2 Libgit2
- 10.3 JGit
- 10.4 go-git
- 10.5 Dulwich
-
A1. Приложение C: Git команди
- A1.1 Настройки и конфигурация
- A1.2 Издърпване и създаване на проекти
- A1.3 Snapshotting
- A1.4 Клонове и сливане
- A1.5 Споделяне и обновяване на проекти
- A1.6 Инспекция и сравнение
- A1.7 Дебъгване
- A1.8 Patching
- A1.9 Email команди
- A1.10 Външни системи
- A1.11 Административни команди
- A1.12 Plumbing команди
5.4 Git инструменти - Подписване на вашата работа
Подписване на вашата работа
Git е криптографски сигурен, но не и дуракоустойчив. Ако вземате код от други хора в Интернет и искате да проверите дали къмитите са действително от надежден източник, Git разполага с начини за подписване и проверка през GPG.
За GPG
Преди всичко, ако искате да подписвате каквото и да е, нуждаете се от конфигуриран GPG и персонален ключ.
$ 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
Ако нямате такъв инсталиран ключ, може да си генерирате с командата gpg --gen-key
.
$ gpg --gen-key
След като веднъж имате частен ключ, можете да настроите Git да го използва за подпис на нещата ви посредством конфигурацията user.signingkey
.
$ git config --global user.signingkey 0A46826A!
Сега Git по подразбиране ще използва този ключ за да подписва тагове и къмити, ако желаете това.
Подписване на тагове
Вече имате GPG частен ключ, да видим как можете да подписвате тагове.
Всичко, от което се нуждаете е да използвате флага -s
вместо -a
:
$ 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
Ако пуснете git show
на този таг, може да видите прикрепена вашата GPG сигнатура:
$ 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 number
Проверка на тагове
За да проверите подписан таг, изпълнете git tag -v <tag-name>
.
Тази команда използва GPG за проверка на сигнатурата.
За да работи това коректно, имате нужда от публичния ключ на подписващия във вашия keyring:
$ 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
Ако не разполагате с публичния ключ, ще получите вместо горния резултат нещо такова:
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'
Подписване на къмити
В по-новите версии на Git (v1.7.9 и нагоре), можете да подписвате също и индивидуални къмити.
Ако искате да подписвате директно къмитите вместо само таговете, трябва да добавите флага -S
към командата git commit
.
$ 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
За да видите и проверите тези сигнатури, на разположение е аргумента --show-signature
за командата git log
.
$ 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
В допълнение, можете да конфигурирате git log
да проверява всички открити сигнатури и да ги показва в изхода си с формата %G?
.
$ 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
Тук можем да видим, че само последния къмит е подписан и успешно валидиран, докато предишните три не са.
В Git 1.8.3 и по-новите версии, git merge
и git pull
могат да се инструктират да проверяват и отхвърлят сливането на къмити, които не носят в себе си trusted GPG сигнатура с опцията --verify-signatures
.
Ако използвате тази опция по време на сливането на клон и той съдържа къмити, които не са подписани и валидни, сливането ще бъде отказано.
$ git merge --verify-signatures non-verify
fatal: Commit ab06180 does not have a GPG signature.
Ако сливането съдържа само валидно подписани къмити, merge командата ще ви покаже всички проверени сигнатури и ще продължи нататък с процеса на сливане.
$ 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(+)
Можете също да ползвате -S
флага с git merge
за да подпишете сами получения merge къмит.
Следващият пример проверява, че всеки къмит в клона, който ще бъде слят е подписан и едновременно с това подписва получения merge къмит.
$ 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(+)
Всеки трябва да подписва
Подписването на тагове и къмити е хубаво нещо, но ако решите да ползвате този принцип в нормалния си работен процес, трябва да се уверите, че всеки в екипа разбира как да го прави. Ако това не е така, ще се озовете в ситуация, в която изразходвате доста усилия и време разяснявайки на колегите си как да преработят техните къмити в подписани версии. Затова е добре да се уверите, че всички в екипа познават добре GPG и ползите от подписването на работата преди да въведете подхода в нормалния работен процес.