「頻繁に」マージする方が良いのですか、それとも機能ブランチの大規模なマージが完了してからですか？

40

複数のブランチが開発されていると言う、AとBだけでなく、増分「バグ修正」ブランチC。

今Cはすでに「完成」しており、マスターにマージされています。AそしてB、まだ開発中であり、（おそらく）別のバグ修正ブランチがmasterにマージされる前に修正されません。

C新しい機能ブランチにできるだけ早くマージすることをお勧めしますか？新しい機能がmasterできるだけ近くにあるように？それとも、新しい機能を完成させてからマスターにマージするだけで、独自の「世界」で開発することをお勧めしますか？

とにかく競合が発生するため、それらの修正に時間を費やす必要があります。

version-control branching merging

— paul23
ソース

2

可能性のある複製フィーチャーブランチをメインラインにマージするための適切な頻度

— gnat

5

機能ブランチをメインラインにマージする@gnatは、「競合を早期に解決する」ために、機能の開発中にメインにフィーチャをマージするのが良いのではないかと考えています。

— paul23

1

@ paul23、それは実際的な必要性だと思います。

— ベリン・ロリッチ

3

正直なところ、モジュールの分離や明確に定義された作業モデルの作成など、コードで適切な設計を使用し始めたときに、バージョン管理に関する多くの問題がなくなりました。マージ中に問題につまづきすぎると、どこかに潜んでいる別の、より深刻な問題が発生する可能性があります。優れた設計は、不必要な競合を回避するのに非常に役立ちます。

— T.

2

後でマージするのが苦痛にならないように、「十分に」近くに留まるために、マスターから定期的にマージすることができます。

— トールビョーン・ラウン・アンデルセン

71

ブランチの寿命が長くなるほど、メインブランチから分岐することができ、最終的に終了するときに結果のマージがより複雑で複雑になります。10の小さな競合は、1つの大規模な競合よりも簡単に解決でき、実際に開発者が重複したり無駄にしたりするのを防ぐことができます。ことを考えると、あなたはマージする必要がありますmasterにAしてB定期的に。1日に1回はかなり一般的な推奨事項ですが、ブランチで多くのアクティビティがある場合は、1日に複数回マージすることをお勧めします。

競合の解決を容易にすることに加えて、特にCバグ修正ブランチについて言及します。開発者として、バグの原因となった動作を繰り返したり、エラーのあるデータに基づいてテストを記述したりしないように、ブランチに最新のバグ修正がすべて必要です。

とにかく競合が発生するため、それらの修正に時間を費やす必要があります。

競合があることがわかっている場合は、別の分岐戦略を採用できます。可能な限り、同じブランチの同じファイルに複数の変更を加えておくと、競合の数を削減または排除できます。ストーリーを可能な限り完全に独立するようにリファクタリングし、ブランチを再作成して複数のストーリーをカバーできるようにします（ブランチ、機能、およびストーリーは常に互換性があるとは限りません）。

— mmathis
ソース

33

多くの場合、リベースによりクリーンなコミット履歴が生成されるため、マージまたはリベースします。

— クリリス

11

@chrylis：「ブランチが複数のストーリーをカバーする」と考えられる場合、2人の開発者が同じブランチで作業することを意味する場合、リベースは危険です。

— メリトン-ストライキ

9

公式ドキュメントの@meriton：リポジトリの外部に存在するコミットをリベースしないでください。人々はそれらに基づいた作業をする可能性があります。そのガイドラインに従えば、大丈夫です。そうしないと、人々はあなたを憎み、あなたは友人や家族に軽cornされます。笑

— エクストリームバイカー

6

@XtremeBiker：Gitのリベースが履歴を変更します。この点で、Gitは現実のように機能します。履歴を変更するには、陰謀が必要です。Git自体のリポジトリには、定期的にリベースされるブランチがあり、非常に公開されています。これが機能する理由は、このブランチを使用するすべての人が特定の時間に履歴を書き換えることに同意するため、その時間までにすべてがマージされる位置にいることを確認するためです。

— イェルクWミッターク

1

@ paul23マスターに配信する前に、AとBを新しい共有ブランチに配信することを真剣に検討してください。両方が根本的なオーバーホールである場合、マスターに組み合わせを与える前に、テストのラウンドのために一緒にしたいです。自信がある場合は、一方をマスターに直接配信し、もう一方を最新の更新されたブランチに配信できます。マージがうまくいかない場合や、何かを再設計する必要がある場合に備えて、2番目の機能の元のコードを確認できるようにしたいでしょう。

— Sinc

11

最終的にA、Bをマスターにマージし、単一のコードベースを維持することを意図していると仮定すると、マスターから離れすぎてしまうことは決して得策ではありません。特にバグ修正などの開発がA、Bの開発中にマスターにマージされる場合、マスターからの逸脱が長すぎると、確かに競合が発生します。

私は次のような戦略を検討します

A、Bの責任者は、マスターを注意深く監視し、変更をマージする必要があります。
さらに良いことに、ビルドとテストの自動化がある場合は、A、Bがマスターにマージされていることを確認し、毎晩テストに合格します。
あなたに基づいて他の答えにコメントすると、A、Bが開発するのに時間がかかるようです。この場合、A、Bを相互にマージすることを検討することもできます。これにより、最終的に両方をマスターにマージする際に大きな問題が発生することはありません。
より高いレベルで、なぜ2つの別個の長期開発が必要なのかを考えてください。小規模な統合に分類できますか？個別のマイクロサービスに分割できますか？

— ケンチュー
ソース

5

通常、多くの場合、大規模なものよりも優れています。

小さく、より頻繁なプルリクエストは、ほぼ常に優れています。

主に構成フラグの使用を開始したのは、初期の小規模なプルリクエストを実行できるようにするためです。これにより、コードをより簡単にマージできますが、機能は無効のままにできます。プルリクエストの数が多い場合でも、プルリクエストが小さいほど、コードを簡単に確認できます。ほとんどの人間は、大規模なプルリクエストの意味のあるレビューを行うことができません。大規模なコード変更の考えられるすべての影響を理解するには、メンタルRAMが非常に困難です。

構成フラグの作成には余分なオーバーヘッドがあるため、小さな機能では価値がありません。ただし、とにかくプル要求は小さくなります。

ただし、機能を一度にリリースする必要がある場合があります。その場合でも、その目的のために作成された別のブランチに対して、より小さなプル要求を行う方が良い場合があります。

私の同僚のほとんどは、誰かが大量のプルリクエストを作成するとうめきます。

また、コミットを別々のブランチにチェリーチェリーする必要がある場合があることに注意してください。チェリーを選択する必要があるものを単一のコミットに入れることができれば、他のブランチに移動しやすくなります。これは、実際にコミットをほとんど行わないほうが良い場合ですが、チェリーを選ぶ場合の正確な標準プロセスではありません。

— マーク・ロジャース
ソース

1

機能フラグは高価になる可能性があります（45分で4億5000万米ドル）。この例は、ボブおじさんにも言及されています（ただし、技術的なことはまったくありません（予想どおり））。

— ピーターモーテンセン

1

ええ、通常はそれほど難しくはありませんが、最終的にそれらを削除するオーバーヘッドがあります。それらをより長く維持するかもしれませんが、フラグはより大きな使用を提供しています。偶然にもフォローアップもせずにやると、事態が悪化する可能性があります。大規模なプルリクエストのレビューが困難になると、事態は悪化する可能性があります。一方、作業中のアプリに設定フラグのようなものを追加する立場にない人もいます。一般に、UATおよび機能の展開に役立ちます。

— マークロジャース

3

Martin Fowlerによるリファクタリングでは、彼が与えるアドバイスは、1日より長くブランチをマスターから分岐させないことです。IIRC、小さな変更を加えて、何も壊していないことを確認するためにテストし、それを元に戻します。

— ジョニーアップルソース
ソース

2

まあAとは、Bアプリケーションの作品は、彼らは月以内に「完了」されていませんどのように主要な斬新なオーバーホールを保持します。それらが行われる前に、しかし、彼らはまた、役に立たないです...

— paul23

8

実行される前に役に立たない場合があります-完全な結果に向けて一歩を踏み出すことで価値を提供し、将来必要な作業を削減します。機能の切り替え、抽象化による分岐、または単にユーザーインターフェイス部分を最後に実行するなどの手法を使用すると、不完全な作業をマスターに安全にマージできるはずです。

— bdsl

1

マスターブランチの変更に基づいてローカルをリベースすることは、長期的な開発に便利な理由です。それはちょうど、最新の分岐されたかのようにあなたの仕事を保ちます

— NKCampbell

2

終了しても使用準備が整っていない可能性のある、非常に長持ちする変更の別のオプションは、それらを機能フラグの後ろに置いて、マスターにマージできるが何も壊さないようにすることです。その後、それらを使用する準備ができたら、機能フラグを削除できます。

— クワルティ
ソース

1

機能フラグ=ゾンビコード（復活するまで）？

— ピーターモーテンセン

@PeterMortensenさて、できるだけ早くフラグを削除する必要がありますが、特定の状況では機能する可能性があります

— Qwertie

3

@PeterMortensenは、フラグが少なくとも1人でオンになっている場合ではありません

— イアン