web-dev-qa-db-ja.com

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

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

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

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

第一

  1. master to fb_＃1（not fb_＃1 to master）をマージして、可能な限り最新にします
  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. 短所：レビューに古いコードが表示される場合があります。

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

gitcode-reviewsbranching
22
Andrzej Gis

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

  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。これにはすべての長所があり、最初のレビューの短所はないようです。

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

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

9
Useless

第三

  • あなたはrebase masterのブランチを最新の状態にし、変更を個別に保持します。

    これにより、ブランチの新しい履歴が作成されます。同じ内容の新しいIDを持つ新しいリビジョンになりますが、最新のマスターから派生し、古いリビジョンにはリンクされません。古いリビジョンを参照する必要がある場合は、「reflog」で引き続きアクセスできます。紛争解決に間違いを見つけたからです。その上、彼らは無価値です。デフォルトでは、Gitは3か月後にreflogをプルーニングし、古いリビジョンを破棄します。

  • interactive rebase（git rebase -iおよびgit commit --amend）変更を並べ替え、編集、クリーンアップして、それぞれが論理的に閉じた変更を行うようにします。

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

  • 長所：

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

通常、余分な作業とは、最初にコードを徹底的にレビューすることを意味し、多くの問題も捕捉されます。

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

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

13
Jan Hudec

GITはSCM方法論の実装よりもSCMフレームワークの実装の方が多いので、実際には3番目の可能性、そしておそらく他の多くの可能性があります。この3番目の可能性はrebaseに基づいています。

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

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

  1. （オプションの手順）トピックブランチtopicをその分岐点にインタラクティブにリベースします（commitの--fixupオプション、および-iと--autosquashオプションを参照） rebase）を使用すると、確認しやすい方法でコミットを書き直すことができます。これにより、ブランチtopic-1が生成されます。

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

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

  4. topic-2が問題ない場合は、マスターにマージします。

[〜＃〜] note [〜＃〜]ブランチ（ここでbranchはコミットツリーを指します）はすべてGITによって同じように呼び出されたため、プロセスの最後では、ブランチtopic-2のみがGITで名前を持っています。

長所：

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

短所：

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

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

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

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

4
Michael Le Barbier Grünewald