バージョン管理で重要なことの1つは、誰がどのような変更を加えたかを知ることです。何かが変わって、なぜ変わったのかわからない場合は、履歴を調べて、変更した人に聞いてみました。私がgitを調べているとき、この機能について少し緊張していることの1つは、偽造が非常に簡単に思えることです。user.nameとuser.emailのgitグローバル設定に同僚の名前/メールアドレスを入れるのを妨げているのは何ですか?gitosis / gitolite(ユーザーを定義した)やgithub(gitosis / gitoliteのようなものを使用していると思います)のようなものを使用する場合、誰が本当にコミットしたかを確認するための理由はありますか?
3 に答える
.gitolite/logs/gitolite-*
Gitoliteは、プッシュごとに Gitolite ユーザーをログイン ( ) します。特定のコミットを導入したプッシュを特定するには、もう少し作業が必要ですが、単純な方法である必要があります (1 つの方法: 各プッシュの先端に軽量タグをドロップgit name-rev
し、コミット後の最初のタグを見つけるために使用します)。
ほとんどの Gitolite ユーザーは、おそらく 1 つの SSH キーしか関連付けられていません ( keydir/user.pub
) が、1 人のユーザーが複数の SSH キーを持つことも可能です ( keydir/user@*.pub
)。
そのため、SSH ベースの Gitolite では、各コミットを 1 つ (または複数) の SSH キーにマップできます。
特定の人物を正確に識別するために SSH キーを信頼するかどうかは別の問題です (つまり、ユーザーが秘密の SSH キーを安全に保つことを信頼しますか?)。
Gitolite は、「スマート HTTP」を介して Git アクセスを管理することもできます。その場合、Web サーバーは REMOTE_USER 環境変数で Gitolite ユーザー名を提供します (つまり、.ssh/authorized_keys
ファイルを使用して SSH キーに基づいてユーザーを識別する代わりに)。識別と認証は完全に Web サーバー自体に委ねられています (通常はユーザー名とパスワードだけですが、ユーザーごとの SSL 証明書を使用して、SSH ベースのアクセスのようなことを行うことができます)。
したがって、HTTP ベースの Gitolite の場合、各コミットを Web サーバーによって行われる認証にマップできます。
GitHub にも同様の情報がいくつかあり、 GitHub APIのイベント部分を介して照会できます(以前は、監視しているリポジトリの「ニュースフィード」エントリの一部としてのみ利用できるようでした)。各PushEventは、プッシュを実行した GitHub ユーザー、更新された参照 (ブランチ) の名前、新しい参照「ヘッド」 (更新されたブランチの新しい先端) の名前 (SHA1 ハッシュ)、およびコミットのリストを識別します。 .
これは倫理や哲学のフォーラムではありません、afaik。しかし
gitは、署名されたコミットと署名されたタグを許可します。これはあなたがあなたのパラノイアを養うのを助けるべきです:)
誰もが GPG でコミットに署名することができます:このチュートリアル を参照してください。
チュートリアルでは、GPG パスフレーズは git config で設定されていますが、これは私にはナンセンスに思えます。そのため、各コミットでユーザーにフック プロンプトを表示する必要があります。
もちろん、あなたがマネージャーでない場合、全員がコミットに署名することを提案することは外交的に困難になる可能性があるため、慎重に行ってください。
編集: ブライアンが指摘するように、これはコミット メッセージに署名するだけなので、良い解決策ではありません。問題を理解するのにまだ役立つかもしれないので、私は答えを保持します。