1

私は、ソース管理/コードレビューとしてGit/Gerritを使用している小さなチームで働いています。
チームの開発者が自分の作業を提出したい場合、彼らはgerritにコミット/プッシュし、新しい機能の作業を開始します。
さらに、開発者は可能な限り自分の作業をプッシュすることをお勧めします。通常、開発者は、現在レビュー中の（関連する変更のチェリーピッキングを通じて）すでに送信された変更に加えて作業します。

問題は、開発者が変更をプッシュしようとすると、変更の履歴もプッシュすることです。副作用として、これらの変更は、同じ変更の以前のバージョンとの違いなしに新しいバージョンを取得します。また、開発者には「偽造」許可を与える必要があります（チェリーが選んだ変更の一部が彼のものではなかったと仮定します）

例：Adamのブランチの1つの履歴が次のようになっているとします（より高い変更が最新です）：

変更3（作成者：Adam、現在作業中）
変更2（Ahthor：チャーリー）
変更1（作成者：Bath）
マスター

現在、変更1、2は、gerritから厳選されたものであり、変更されていません。
アダムがパッチをプッシュするとき、彼は変更1、2でコミッターを偽造できなければならず、それらは新しいバージョンを取得します（以前のプッシュとの違いはありません）

誰かがこの動作を回避する方法をアドバイスできますか？私たちは何か間違ったことをしていますか？

4

2 に答える 2

2

Gerrit is creating new versions of these patchsets because there were changes - when the developers cherry-picked the changes that are up for review, that modifies the git commit. The commit now has a different parent and a different SHA1.

There are 2 ways to avoid this:

  1. Take the time to properly review/verify/merge changes that are still under review before doing much more work on top of them
  2. Rather than cherry-pick the changes down locally, use checkout. This will keep the existing patchset as-is, so any commits on top will upload fine without modifying the existing patchset. However, this will move your place on the repository to where the patchset was when it was created - you won't have any commits that have been merged since that patchset was uploaded.

デイジョブでは、状況に応じてこれら2つのアプローチを組み合わせて使用​​します。幸運を！

于 2012-10-22T21:47:50.513 に答える
1

弊社でも同様の問題がありました。Gerritには、ローカルリポジトリに追加する必要のあるスクリプトが付属しています（Windows、Mac、およびLinuxで動作します）。ローカルリポジトリに対してコミットが行われると自動的に実行され、コミットIDが生成されます（コミットメッセージの最後に追加されます）。

後でコミットのSHA1が変更された場合（たとえば、修正のため）、Gerritはそれが同じコミットであると認識し、新しいエントリポイントを作成しません。コミットがまだレビュー中の場合は、ファイルを更新するだけです。

スクリプトをコピーするには、リポジトリに移動して次の手順を実行します。

scp -p -P 29418 username@path.gerrit.server.com:hooks/commit-msg .git/hooks/
于 2012-10-22T17:02:43.613 に答える