2016-04-13 21 views
0

次のシナリオを検討してください:gerritが他のコミットを変更しないようにするにはどうすればいいですか?

  1. アリスはボブのチェックアウト/チェリーピックは、それがまだマスターに提出されていないコミットます。

  2. ボブは、このコミットのために新しいパッチセットをプッシュします。アリスはそれを知らない。

  3. アリスは、古いバージョンのボブのコミットに基づいて新しいコミットをプッシュし、gerritはボブのコミットに新しいパッチセットを適用し、Change-IDに基づいてボブの最新の変更を上書きします。

git/gerritにこのような状況を防ぐ手段はありますか?

答えて

0

私はgitの前プッシュフックを使用して必要なものを実装します。 私の.git/pre-pushファイルの内容は次のとおりです。

#!/bin/sh 

# A hook script to verify what is about to be pushed. Called by "git 
# push" after it has checked the remote status, but before anything has been 
# pushed. If this script exits with a non-zero status nothing will be pushed. 
# 
# This hook is called with the following parameters: 
# 
# $1 -- Name of the remote to which the push is being done 
# $2 -- URL to which the push is being done 
# 
# If pushing without using a named remote those arguments will be equal. 
# 
# Information about the commits which are being pushed is supplied as lines to 
# the standard input in the form: 
# 
# <local ref> <local sha1> <remote ref> <remote sha1> 

AUTHOR=$(git var GIT_AUTHOR_IDENT) 

while read local_ref local_sha remote_ref remote_sha 
do 
    commit_author=$(git log -1 --pretty=format:"%ae" $local_sha) 
    #echo $local_ref $local_sha $remote_ref $remote_sha $commit_author 
    found=`echo $AUTHOR | grep -c "$commit_author"` 

    if [ $found == 0 ] 
    then 
     echo 
     echo "REJECTED by local pre-push hook:" 
     echo "You are trying to push some other's commit: $local_sha $commit_author" 
     echo "Use --no-verify if you are sure this is not an error" 
     exit -1 
    fi   
done 
echo "Local pre-push verify passed ok" 
exit 0 
0

あなたが「フォージ著者」既定のアクセス許可を変更することができます。

通常ヘリットは いずれかに一致する(注釈付きタグや鬼ライン)オブジェクトをコミットGitの中で作者とコミッタのアイデンティティライン が必要ですアップロードされたユーザの登録された電子メールアドレスのこの パーミッションを使用すると、アップストリームプロジェクトから変更をミラーリングするときに、 が必要な検証の一部をバイパスすることができます。

コミットオブジェクトで未確認の作成者行の使用を許可します。これは、他の人が の支店で行った変更をチェリーピッキングするとき、または送信前にマイナー 問題を修正する他の人のコミットを修正するときに、3番目の パーティーから電子メールで受け取ったパッチを適用するときに役立ちます。

デフォルトでは、これはすべてのプロジェクトの登録ユーザーに付与されますが、サイト管理者は、確認された作成者が が必要な場合は無効にすることがあります。

さらに詳しい情報:https://gerrit.cpqd.com.br/Documentation/access-control.html#category_forge_author

+0

ありがとうございます。それは合理的だと思いますが、1000人以上のエンジニアが組織内でサーバー全体を大きく変更するのはかなり難しいです。私の望みは、何らかの事前コミット・フックをユーザーや小規模なチームに特化させることでした。 – ksushchyk

+0

特定のユーザーに使用されている特定のリポジトリー(プロジェクト)に対してのみ許可を設定することは可能です/チーム。 –

関連する問題