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

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

6 голосов
/ 11 марта 2010

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

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

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

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

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

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

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

Ответы [ 3 ]

2 голосов
/ 11 марта 2010

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

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

Для вашего рабочего процесса вы можете просто найти много тегов.

0 голосов
/ 11 марта 2010

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

-s 

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

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

0 голосов
/ 11 марта 2010

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

  • каждый коммит уже подписан
  • ключа SHA1 для каждого коммита достаточно, чтобы убедиться, что репо all не было изменено
  • git tag -s можно использовать для подписания коммита, который кто-то не сделал (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-of-line в конце сообщения о коммите : см. На этой странице объяснение о подписании процесс. 

    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.
(См. commit ba3c69a9 , улучшенный совсем недавно в commit df45cb3 )

...