Надежный путь разработки в git с сигнатурами

Question

Я хотел бы создать надежный путь для разработки программного обеспечения.Это означает, что каждое изменение в коде должно быть подписано автором и одним рецензентом, прежде чем оно будет принято.Эти подписи для изменения должны поддаваться проверке во время выпуска, или должны существовать какие-либо другие способы убедиться, что хранилище не могло быть подделано или добавлены дополнительные изменения.

Система контроля версий, которую я ожидаю использовать для этого, - это git, но принимаются и другие варианты.Подписание может осуществляться с помощью Сертификатов GnuPG или SSL.

Рабочий процесс, о котором я думаю, был бы примерно:

1. Текущая проверенная магистраль разветвлена
2. Изменения разрабатываются в ветке одним или несколькими разработчиками
3. Один или несколько разработчиков подписывают изменения, внесенные филиалом
4. Рецензент рассматривает и тестирует изменения
5. Рецензент подписывает изменения, внесенные филиалом
6. Ветвь "объединена" с текущей проверенной магистралью

Слияние не обязательно должно быть надежным, таким как unreview изменения должны быть недоступны для trunk - только это перед выпуском должен быть способ проверить, есть ли какие-либо непросмотренные (неподписанные) изменения в магистрали.И вообще, вмешательство не нужно предотвращать, его нужно только обнаружить.

Я хотел бы получить краткое руководство о том, как это настроить и как выполняется каждая операция.Как только я получу некоторые указания, я смогу сам разобраться в деталях.

Кроме того, я уже знаю о 'git tag -s' технически, но я не уверен, как применить его к этой конкретной проблеме.

Answer 1

Изменения не будут подписаны до тех пор, пока вы не пометите их тегом.Все, что предшествует этому моменту, может быть проверено автором или другим внешним механизмом, но не изнутри git.

git может проверить правильность наследия изменения, но только подписанный тег может проверить правильность самого изменения.

Что касается вашего рабочего процесса, вы можете просто обнаружить, что часто помечаете его тегами.

Answer 2

Вы можете подписать свой тег своим ключом GPG с опцией -s в теге git tag -s v0.1.0:

-с

   Make a GPG-signed tag, using the default e-mail address's key

Но вы не можете подписать коммит.

Answer 3

Git - хороший кандидат, так как:

• каждый коммит уже подписан
• ключа SHA1 для каждой фиксации достаточно, чтобы быть уверенным в ВСЕ репо не было изменено
• тег -ы git можно использовать для подписи коммита, который кто -то не совершал (git tag -m является более явным)

Итак:

1. Текущая проверенная магистраль разветвлена

   git checkout -b tag_for_last_verified_trunk_content test # branch test

2. Изменения разрабатываются в ветке одним или несколькими разработчиками

   [work...] git commit -s -m "dev1 comment" ...

3. Один или несколько разработчиков подписывают изменения, внесенные филиалом

   Уже сделано с их фиксациями, путем добавления Подписанной строки в конце сообщения о фиксации:смотрите эту страницу для объяснение по поводу подписанного процесс.

   Signed-off-by: user name 

4. Рецензент рассматривает и тестирует изменения

    git tag -m "testing" testing # refer to current commit, 
                                   allowing dev to go on with further changes

5. Рецензент подписывает изменения, внесенные филиалом

   git tag -m "tested" tested testing # put a tag on the same SHA1 than 
                                        the "testing" tag

6. Ветвь "объединена" с текущей проверенной магистралью

   git checkout trunk & git merge tested

---

Cyryl Plotnicki-Chudyk упоминания в комментариях что, начиная с git 1.7.9 (январь 2012, почти через 2 года после этого ответа), вы можете GPG-подписать любой коммит, который вы хотите, используя git commit -S.
(См. зафиксировать ba3c69a9, усовершенствованный совсем недавно в фиксация df45cb3)