1

私たちのビジネスでは、次のセットアップ（非常に簡略化されたバージョン）があり、かなり標準的です。

  • フックを介してライブ環境を更新するマスターブランチ。
  • QA、UAに使用されるテストブランチ。同じ方法でテスト環境を更新します。

リポジトリはGitHubでホストされています。

ワークフローは通常次のとおりです。

  • マスターから引っ張る
  • 特定のチケットで作業するためのブランチ（Ticket1など）を作成します
  • 作業を行い、ローカルでテストします
  • ブランチTicket1をコミットしてプッシュする
  • githubのプルリクエストを介してTicket1をテストにマージします。これにより、ピアコードレビューなどを行うことができます。

とても標準的です。時々遭遇するテストブランチにプルリクエストを行うとき、プルリクエストで、githubは開発者によって行われたと思われるコミットよりも多くのコミットを表示します。調査の結果、それが発生したときに少なくとも1つの特定のケース（これが唯一のケースではない可能性があります）に気づきました。

  1. 開発者Aは、テストにいくつかの変更を加え、QAとUAに合格し、マスターとマージされます。
  2. 開発者Bはさらにいくつかの変更を加えます。マスターとマージするとき、競合があります。開発者Bは競合を解決し、IDが1234567などの新しいコミットで競合の修正をコミットします。
  3. 開発者Aは別のチケットの作成を開始します。マスターからプルし（したがって1234567コミットをプルします）、ブランチを作成し、コミットし、プッシュします。GitHubでプルリクエストを行ってブランチをテストにマージすると、GitHubはコミットと1234567をマージしたいと考えます。彼はその特定のコミットについて何も知らないので、それは彼を怖がらせます。

私は同様の質問を検索しましたが、少なくとも次のことを見つけました。

彼らはコマンドラインソリューションを扱いました（基本的には「rebase」を使用）。しかし、彼らは私たちの根本的な問題を扱っていません。それは、それが起こらないようにする方法です。なぜそれが起こるのか、つまりいつ起こるのかを知りたいのですが、ワークフローに根本的な欠陥があるのか​​、githubがプルリクエストを作成する方法に関する何かが欠けているのかはわかりません。

確かに、これは以前にあなたに起こったに違いありません。どのように対処しますか？

4

1 に答える 1

1

手続き上の「ロック」の問題があり、さまざまなチケットブランチの開始点とそれらのマージポイントがプルポイントと最終的なマージおよび修正ポイントの間で重複していると推測しています。

開発者は、プルリクエストでticket1を終了したと考えていますが、マージと修正が[時間/日後？]になるまで、実際にticket2のブランチを開始するべきではありません。そうしないと、ticket2の開始時に修正が実際に表示されません。次に、ticket2がプルされても、まだ修正が含まれていないため、再適用する必要があるようです。

チケットマージループの線形シーケンスが必要な場合、開発者は、プルリクエストを発行する直前に、マスターを再フェッチし（合意されたすべての修正を加えて！）、リベースを実行する必要があります。

gitkなどを使用して、これらの問題の1つのポイント周辺のすべてのブランチを視覚化し、タイムスタンプとレビュー会議時間をチェックして、それが隠れたデッドゾーンであるかどうかを確認します。

于 2012-08-09T20:55:55.080 に答える