問題タブ [gerrit]

バージョン管理システムとして git を使用し、コード レビューを行うために Gerrit サイトをセットアップしました。次のことを行うフックを作成したいと思います。

• 管理者が [送信] ボタンをクリックすると、ファイル ( version.txt ) が変更されます。
• スクリプトはファイルを開く必要があります。

• 次のテキストを見つけます (ID が変わる可能性があります)。

  #version Change-Id: Ie1411d50f6beb885bc3d3b7d8c587635e1446c18

• Change-Id を新しいパッチの Change-Id に置き換えます。

• したがって、マージされるパッチに がある場合、スクリプトの実行後Change-Id: I1c25f7b967084008b69a6a8aefa6e3bb32967b82にversion.txtファイルに次の文字列が含まれている必要があります。

  #version Change-Id: I1c25f7b967084008b69a6a8aefa6e3bb32967b82

• 次に、フックは新しいコミットを作成し (ファイルの 1 つに変更があったため)、この最後のコミットを master にプッシュする必要があります。

これは、変更マージされたフックを使用して可能になると思います。私は正しいですか？

前もって感謝します。

GITリポジトリがあります。GITの変更をGerritにプッシュすると、jenkinsビルドがトリガーされ、成功すると、コードがGITリポジトリにマージされます。

しかし、Jenkinsは常にGITリポジトリからソースを構築しています。Gerritにプッシュされた変更を選択していません。

Gerrit / Jenkinsでどの設定を変更する必要がありますか？

Gerritは、コミット履歴の初期にあり、リポジトリの別の「ブランチ」にある、レビューされていない可能性のある変更をマージします。次に例を示します。

1. チェックアウトジェリットブランチdevel
2. file1.txtを作成し、追加し、コミットし、プッシュしますrefs/heads/temp_branch
3. file2.txtを作成し、追加し、コミットし、プッシュしrefs/for/develてコードレビューを行います

file2.txtが受け入れられてマージされると、file1.txtはアップストリームであり、レビュー中としてフラグが立てられた別の変更ブランチにないため、マージされます。これは潜在的に非常に問題があり、私が思いつく唯一の解決策はすべてのブランチにプッシュされたすべての変更をコードレビューするように強制します。これは理想的ではありません。1つのグループの承認者がいるブランチや、コードレビューがないブランチ（コードスワッピングの場合）が必要な場合があるためです。

ここでの解決策は、file1.txtが同じリポジトリ内の別のブランチにプッシュされなかった場合のように、履歴内のすべてのコミットをコードレビューに強制的に配置することです。

このルールを課す設定はGerritにありますか？refs/heads/他のブランチを汚染するリスクを冒すことなく、自由にプッシュできるワークフローを誰かが考えることができますか？

どうもありがとう。

新しい変更がアップロードされるたびに通知されるように、gerrit プロジェクトをサブスクライブするにはどうすればよいですか。

ありがとう、ラヴィ

ブランチ 'a' の名前を 'master' に変更し、'master' の名前を gerrit で 'b' に変更するにはどうすればよいですか?

最近、共有 git リポジトリから gerrit に切り替えました。

SourceTreeをGerritにプッシュする方法がわかりません。

私はこのリンクを見ましたが、それがどのように行われるのかまだわかりません： https ://answers.atlassian.com/questions/29361/configuring-sourcetree-push-for-gerrit

どうやら1.3.3のリリースノートによると、それを行う方法はありますが、私にはわかりません：http: //www.sourcetreeapp.com/update/ReleaseNotes.html#version-1.3.3

それを行う方法について、どこかにステップバイステップガイドがありますか？

今、私はこのコマンドをターミナルで実行してプッシュします

cgit を定期的に実行すると、(gerrit が JGit でレポを操作するため) 何らかの害が生じますか? JGit はこの機能を自動的に実行しますか?

大規模なプロジェクトで Gerrit の使用を検討しています。この時点で、承認された変更のマージ競合に人々がどのように対処しているかを知ることは興味深いでしょう。

さまざまなサイズの多くの変更が同時に改訂保留中であり、それらが徐々にレビューおよび検証されていると想像してください。それらの一部は同じコードを変更している可能性があるため、競合は避けられません。「インテグレーター」が単純なワークフローで手動でパッチを受け入れる場合は問題ありません。小さな競合は途中で解決できますが、Gerrit では事情が異なります。変更がレビューされて承認された後、マージの競合が発生した場合、私が理解しているように、作成者によってリベースされ、改訂のために再度プッシュされる必要があります。その場合、改訂プロセスが再び開始されます。比較的活発なプロジェクトでは、1 週間に 50 件を超える外部貢献者のコミットがあり、これは悪夢に変わる可能性があります。

質問:

1. Gerrit は、多数のマージ競合が予想される大規模でアクティブなものを前進させる方法ではないということは正しいですか?

2. いくつかのマージの競合は些細なことかもしれません。作成者が変更を再コミットするのを気にせずにそれらを解決する方法はありますか?

3. 変更を安定したブランチにバックポートする必要がある場合は、チェリーピックがクリーンであっても、各ブランチの個別の変更をプッシュして改訂する必要があると思います。

Gerrit ワークフローの経験に関する一般的なコメントも歓迎します。

自動テストとコードレビューのためのgit、gerrit、jenkinsを含む新しいCIシステムのセットアップを完了しているところ、奇妙な状況が見つかりました。

3つの異なるgerritプロジェクトがあり、それぞれが独自のJenkinsジョブを持っています。このガイドをセットアップリファレンスとして使用しましたが、すべてがインストールされており、正常に機能しているようです。

最初のプロジェクトはセットアップされ、サンプル変更パッチでテストされました。Jenkinsは正しくトリガーされ、テストに合格し、期待どおりにビルドに「検証済み」と投票しました。ここまでは順調ですね！

ただし、2番目のプロジェクトをセットアップしようとすると、プロジェクトトリガーの1つにある変更パッチが、すべてのjenkinsジョブで変更されていることがわかりました。例えば：

GerritProjectAとGerritProjectBがあり、それぞれにJenkinsProjectAとJenkinsProjectBがあるとします。変更がGerritProjectAに送信されると、JenkinsProjectAとJenkinsProjectBの両方がトリガーされます。また、ビルド後のgerrit投票で何かが混乱します。これは、ビルドの1つ（JenkinsProjectBの1つ）の後のsshd_logの情報です。

ご覧のとおり、gerrit approveコマンドは、2つの異なるjenkinsジョブの情報と混同されています...

jenkinsジョブのサンプルセットアップ：

ソフトウェアバージョン：

何か案は？前もって感謝します！

ドミンゴ