機能ブランチからマスターにマージする前のコードレビューの戦略

私と私のチームは機能ブランチを使用しています（gitを使用）。マスターにマージする前に、コードレビューの最適な戦略はどれかと思います。

1. マスターから新しいブランチをチェックアウトし、fb_＃1と呼びます
2. 私は数回コミットし、それをマスターにマージしたい
3. 私がマージする前に誰かがコードレビューをすることになっています

現在、2つの可能性があります。

1日

1. 私はマージ＃1 FB_するマスターを（いない最新のできるだけそれを作るためにマスターにFB_＃1）
2. チームメイトがマスターヘッドとfb_＃1ヘッド間の変更を確認します
3. fb_＃1で問題なければ、fb_＃1をマスターにマージします
4. 長所：廃止されたコードはレビューされていません
5. 短所：他の誰かが「1」の間に何かをマージする場合 および「2.」彼の変更はレビューに表示されますが、別のレビューに属します。

2番目

1. チームメイトがチェックアウト（git merge-base master fb_＃1）とfb_＃1 headの間の変更をレビューします
2. 長所：機能ブランチでの作業中に変更された内容を正確に把握できます
3. 短所：一部の古いコードがレビューに表示される場合があります。

あなたはどちらの方が良いと思いますか、なぜですか？別のより適切なアプローチがありますか？

あなたの最初のオプションのバリエーションがあります：

1. マスターをfb_＃1（fb_＃1ではなくマスター）にマージして、可能な限り最新の状態にします。
2. チームメイトは、マージした時点のマスターとfb_＃1ヘッドの間の変更をレビューします
3. fb_＃1で問題なければ、fb_＃1をマスターにマージします
4. マージに問題がないことを簡単に確認する

例えば。

... ma -- ... -- mm -- ... -- mf  <- master
      \            \         /
       f1 ... fn -- fm -----      <-- fb_#1

ここで：

• maはmasterとfb_＃1の祖先です。
• fnはブランチの最後の変更です
• mmはブランチにマージした時点でmaster / HEADだったコミットです（fmを与えます）。

そのため、最初のレビューでmmとfmを比較し、mfをマージしてすぐにチェックして、手順1〜3でmasterに大きな変更が加えられていないことを確認します。これにはすべての長所があり、初期レビューの短所はないようです。

これは、マスターにプッシュされる変更の通常の頻度と比較してレビューが迅速であると想定しているため、多くの場合、fm-> mfは早送りになります。

そうでない場合は、何らかの理由で、短所は最初のレビューからマージ後レビューに移動するだけで、マスターに直接マージしてそこで単一のレビューを行う方が簡単かもしれません。

3番目

• あなたはリベース両方メイクそれが最新にマスター上でブランチをし、変更が分離しておきます。

  これにより、ブランチの新しい履歴が作成されます。同じコンテンツを持つ新しいIDを持つ新しいリビジョンになりますが、最新のマスターから派生し、古いリビジョンにはリンクしません。競合の解決に誤りを見つけた場合など、参照する必要がある場合、「reflog」で古いリビジョンにアクセスできます。それに加えて、彼らは無価値です。Gitはデフォルトで3か月後にreflogを整理し、古いリビジョンを破棄します。

• あなたは使用インタラクティブリベース（git rebase -iとgit commit --amend）並べ替えるには、編集をして、それぞれが論理的に閉じられた変更を行いますので、変更をクリーンアップします。

  これにより、再び新しい履歴が作成されます。今回は、変更を再構築してレビュー中に最も意味を持たせることができるという利点が追加されています。

• 長所：

  • 廃止されたコードはレビューされていません
  • 機能ブランチでの作業中に何が変更されたかを正確に確認します
• 短所：
  • もう少し仕事
  • 既にマージされたものや共有したものをリベースしないように注意する必要があり、受信者はそれが巻き戻されることを期待していません。

通常、余分な作業は、最初に自分でコードを徹底的にレビューすることを意味し、多くの問題もキャッチします。

これがLinuxとGitの機能です。そして、それらのプロジェクトで20〜25の一連のパッチがレビューのために提出され、何度も書き直されるのは珍しいことではありません。

実際、Linuxはプロジェクトの早い段階からバージョン管理がtarballとパッチであったときにそれを行いました。数年後、Linusがgitの作成に着手したとき、それがrebaseコマンドを実装する主な理由であり、インタラクティブなバリアントです。また、そのためにgitは著者とコミッターの概念を分けています。作成者は最初にリビジョンを作成した人であり、コミッタは最後に修正した人です。LinuxとGitの両方でパッチはまだ電子メールで送信されているため、この2人が同じ人物になることはほとんどありません。

GITはSCM方法論の実装というよりもSCMフレームワークの実装であるため、実際には3番目の可能性があります。この3番目の可能性はに基づいていrebaseます。

rebaseGITサブコマンドは、（一般的に、あなたの分岐点から、あなたのトピックブランチの先端にコミットする一連の取りtopic）と（例えば、一般的に、統合ブランチの先端にどこかにそれらを再生しますmaster）。このrebaseサブコマンドは、新しいコミットを生成します。これにより、確認しやすい形式でコミットを再配置することができます。これにより、topic以前と同様の新しい一連のコミットが生成されますが、統合ブランチの最上部に根付いているように見えます。この新しいブランチはまだtopicGITによって呼び出されるため、古い参照は破棄されます。topic-0ブランチの元の状態などを非公式にラベル付けtopic-1し、さまざまなリファクタリングを行います。

あなたのtopicブランチに対する私の提案は次のとおりです。

1. （オプションステップ）あなたが対話的にあなたのトピックブランチをリベースtopicその分岐点に（参照--fixupのためのオプションcommitと-iして--autosquashのオプションをrebaseあなたのレビューが容易である方法であなたのコミットを書き換えるための機会を与えます、）。これにより、ブランチが作成されtopic-1ます。

2. 統合ブランチの最上部でトピックブランチをリベースします。これはマージを行うのと似ていますが、単なるソフトウェアエンジニアリングアーティファクトであるマージで履歴を「汚染しません」。これにより、ブランチが作成されtopic-2ます。

3. topic-2の先端に対してそれをレビューするチームメイトに送信しますmaster。

4. よければtopic-2、それをマスターにマージします。

NOTE枝- 枝が木になるすべてのため、プロセスの最後に、唯一の支店は、GITによって同じと呼ばれるコミットを指しtopic-2GITに名前を持っています。

長所：

• 廃止されたコードはレビューされていません。
• 偽の「外部マージ」レビュー（1日で説明した現象）はありません。
• クリーンな方法でコミットを書き換える機会。

短所：

• 1つのブランチの代わりに、topic-03つのブランチアーティファクトtopic-0が topic-1ありtopic-2、それらはコミットツリーに作成されます。（ただし、GITで名前を持っているのはいつでも1つだけです）。

最初のシナリオでは、«誰かが「1」の間に何かをマージした場合 「2.」»は、分岐点の作成からマージを決定するまでの時間を指します。このシナリオでは、«誰かが「1」の間に何かをマージした場合 「2.」»は、リベースからマージまでの時間を指し、通常は非常に短い時間です。したがって、私が提供するシナリオでは、masterワークフローを大幅に乱すことなく、マージの時間の間ブランチを「ロック」できますが、最初のシナリオでは実用的ではありません。

体系的なコードレビューを行っている場合は、適切な方法でコミットを再配置することをお勧めします（オプションのステップ）。

中間ブランチアーティファクトを管理するのは、リポジトリ間でそれらを共有する場合にのみ困難です。