Доверяемый путь разработки в мерзавце с подписями
Я хотел бы создать доверяемый путь для разработки программного обеспечения. Это означает, что каждое изменение в кодировать должно быть подписано автором и одним рецензентом, прежде чем быть принятым. Эти подписи для изменений должны поддаваться проверке во время выпуска, или должны быть некоторые другие средства проверки, что репозиторий не мог вмешаться, или дополнительные добавленные изменения.
Система управления версиями, которую я ожидаю использовать для этого, является мерзавцем, но другие опции также приняты. Подписание может быть через GnuPG или сертификаты SSL.
Рабочий процесс я думаю, был бы примерно:
- Текущая проверенная соединительная линия переходится
- Изменения разрабатываются в ответвлении одним или несколькими разработчиками
- Один или несколько разработчиков подписывают изменения, внесенные ответвлением
- Рецензент рассматривает и тестирует изменения
- Рецензент подписывает изменения, внесенные ответвлением
- Ответвление "объединяется" в с текущей проверенной соединительной линией
Слияние не должно быть надежное, такие как, нерассмотренные изменения должны были бы быть unmergeable для транкинга - просто что перед выпуском, должен быть способ проверить, существуют ли какие-либо нерассмотренные (неподписанные) изменения в соединительной линии. И в целом, вмешательство не должно быть предотвращено, только обнаружено.
Я хотел бы краткий справочник о том, как настроить это и как каждая операция сделана. После того как я получаю некоторые указатели, я могу выяснить специфические особенности сам.
Кроме того, я уже знаю о '-s' тега мерзавца технически, но я не уверен, как применить его к этой конкретной проблеме.
3 ответа
Изменения не будут подписаны, пока вы не поставите метку. Всё, что до этого момента, может быть проверено автором или другим внеполосным механизмом, но не из git.
git может проверить правильность наследия изменения, но только подписанный тег может подтвердить правильность самого изменения.
Для вашего рабочего процесса, возможно, вы просто обнаружите, что часто ставите метки.
Вы можете подписать свой тег с помощью ключа GPG с параметром -s в теге git tag -s v0.1.0 :
-s
Сделать тег, подписанный GPG, используя значение по умолчанию ключ адреса электронной почты
Но вы не можете подписать фиксацию.
Git является хорошим кандидатом, так как:
- каждая фиксация уже подписана
- ключ SHA1 для каждой фиксации достаточно, чтобы быть убедитесь, что репозиторий all не был изменен
- теги git -s можно использовать для подписания фиксации, которую кто-то не делал (
тег git -mболее явный )
Итак:
- Текущий подтвержденный ствол ветвится
git checkout -b tag_for_last_verified_trunk_content test # branch test
- Изменения вносятся в ветку одним или несколькими разработчиками
[работа ...] git commit -s -m "dev1 comment" ...
Один или несколько разработчиков подписывают изменения, внесенные веткой
Уже сделали со своими коммитами, добавив строку с подписью в конце сообщения фиксации : см. эту страницу для объяснения процесса подписания .
Подписано: имя пользователя
Рецензент просматривает и тестирует изменения
git tag -m "testing" testing # относится к текущей фиксации, позволяя разработчикам продолжить changes
- Рецензент подписывает изменения, внесенные веткой
git tag -m "Test" Test testing # помещает тег в тот же SHA1, что и " test "tag
- Ветвь" объединена "с текущим подтвержденным стволом
git checkout trunk & git merge протестировано
Цирил Плотницки-Чудык упоминает в комментариях говорится, что, начиная с git 1.7.9 (январь 2012, почти 2 года после этого ответа), вы можете подписать GPG любой коммит, который хотите, используя git commit -S .
(См. commit ba3c69a9 , уточнено недавно в commit df45cb3 )