長時間実行される未リリースコードのGit分岐戦略

私たちのチームでは、個々の作業単位（ストーリー）に加えて、より長時間実行される作業テーマ（叙事詩）があります。複数のストーリーが壮大です。

従来、各ストーリーに機能ブランチがあり、それらがQAに合格したときにそれらを直接マスターにマージしました。ただし、Epicが「機能完了」と見なされるまで、Epicで完了したストーリーのリリースを控えたいと思います。これらの機能は、Epic全体が閉じられたときにのみ本番環境にリリースされます。さらに、ナイトリービルドサーバーがあります-すべての閉じられたストーリー（不完全なEpicsの一部を含む）がこのナイトリーサーバーに自動的にデプロイされるようにします。

これを達成するためのレポの管理方法に関する提案はありますか？「エピックブランチ」を導入することを検討しました。ここでは、クローズドストーリーをマスターに直接ではなく、関連するエピックブランチにマージしますが、私の懸念は次のとおりです。

壮大なブランチを長時間開いたままにしておくと、マージの競合が心配です
ナイトリービルドでは、すべてのエピックブランチを「ナイトリービルド」ブランチにマージする必要があります。繰り返しますが、マージの競合が発生する可能性があり、これは自動的に行われます

— シタティ
ソース

回答:

簡単な提案：それをしないでください。

gitブランチは、ここおよびhttps://blog.newrelic.com/2012/11/14/long-running-branches-considered-harmful/で説明されているように、コードの長時間実行フォーク用ではありません。ブランチは、日々のレベルで個々の開発者によってコミットを整理するために使用される一時的なものとして最もよく扱われます。そのため、プロジェクトマネージャー（エンドユーザーはもちろん）が何かに対応する名前を持っている場合、あなたが何か間違ったことをしていることに気付くかもしれません。

推奨されるプラクティスは、機能の切り替えまたは抽象化によるブランチとの継続的な統合を使用して、次のことを確認することです。

すべてのコードは常に統合されています（少なくとも毎日、できればより頻繁に）
デプロイされるものは明示的に制御されます。

— そる
ソース

これは人気のある答えだと思いました！これに関する私の主な懸念は、「ライブ」と「次の」実装の両方を常に維持するオーバーヘッドです。また、機能に取り組んでいる開発者が、アップグレード（/既存の機能。チームの大きな考え方の変更が必要だと思います。

— シタティ

コードを開発するためにブランチを使用しても構いませんが、コードを保存するためにブランチを使用しないでください。そのため、タスクが30分間の修正か2週間のやり直しかわからない場合は、ブランチから始めます。わかったらすぐに、抽象化/トグルにマージまたはリファクタリングしてからマージします。

— -soru

@Sitati：過去4か月間、機能ブランチにあったコードをマージしました。それdevelまでの間、AutotoolsからCMakeに切り替え、Travis CIを導入し、コードをリファクタリングしました。最終的に、新しい機能を理解し、それdevelをマージしようとするよりも手動で適用する方が簡単でした。新しい修士課程の学生には、論文を始めたときに分岐したブランチで新しい機能を開発させました。1年後、彼らはそれをプッシュし、それを元に戻す努力がなかったので、毎日マージするのが難しくなりました。

— マーティンUeding

リンクされたブログ投稿は5年目です。機能の切り替えが嫌いです。長期的なブランチ、メインから機能ブランチへの定期的なマージ、および長期的な機能ブランチへの継続的な統合の追加の何が問題になっていますか？

— ジェイソンケリー

CIはプロセスの名前であり、ツールではありません。複数の機能ブランチがある場合、それらは通常互いに継続的に統合されません。つまり、問題をすぐに見つけるのではなく、後で見つけることになります。

— soru

これは非常に一般的な問題だと思うので、機能をコーディングする前ではなく、リリース後にどの機能を含めるかを選択することになります。

例えば。

製品のv2の機能A、B、Cがあります。BとCは関連しています。Cも終了しない限り、Bをリリースしたくありません。

私は3人の開発者がすべて同時に機能に取り組んでいます。

石の発売日が設定されていますD

Bは終了してマージされ、Aは終了してマージされます。Cは遅延します...どうすればよいですか？！

この問題に対する技術的な解決策があるとは思わない。機能Aのみが含まれる、テストされていないバージョンの製品をリリースします。機能の可能なすべての組み合わせをマージしてテストしない限り、これは常に可能性があります。

解決策はより人間的なものです。リリース日を逃したため、プッシュする必要があります。

— ユアン
ソース

これは難しい問題ですが、多くの人が直面する問題です。開始点としてGitflowセットアップを使用することを好みます。

開発->
マスターで作業中の新しいもの->テストが必要な完成したもの生産->生産に公開されたもの。

マイナー（より短い）機能では、開発からブランチを作成し、そこで作業を行い、ブランチを開発にマージします。

主要な（長期）機能では、開発からブランチを作成し、そのブランチから小さなブランチを作成してから、最初のブランチにマージします。主要な機能が完成したら、開発ブランチに戻ります。

定期的に（プロジェクトによって異なります）、開発をマスターにマージし、テストサイクルを開始します。テストで修正が行われた場合、それらはマスターブランチで行われます（サブブランチがマージされます）。また、テスト中にmasterブランチで開発を継続できます。

マスターはいつでも開発にマージする必要があり、開発はその長期サブブランチのいずれかにマージする必要があります。

マスターは常に（理論上）生産の準備ができている必要があります。開発は常に（理論上）生産の準備ができている必要があります。唯一の理由は、テスターがテストするための堅牢な機能セットを提供することです。

準備ができたら、テストされたマスターでのコミットが本番環境にマージされ、本番環境での展開がそのブランチから行われます。緊急時に行う必要のあるHOTFIXは、マスター（多くの未テストの変更がある可能性があります）にマージすることなく、実稼働ブランチで実行できます。

私の通常のツリーは次のようになります

 LongTerm -> Development -> Master -> Production    
 LongTerm <- Development      |            |  
     |       Development -> Master         |  
 LongTerm <- Development -> Master         |  
             Development <- Master         |  
                            Master -> Production

私の一般的なルールでは、単一の変更に数時間以上かかることはありません。その場合は、より小さな変更を加える必要があります。それが巨大な機能（UIの書き換えなど）である場合は、通常の開発を同時に継続できるように、長期にわたって行われます。LongTermブランチは通常ローカルブランチのみですが、Development、Master、およびProductionはリモートブランチです。サブブランチもローカルのみです。これにより、長期の機能セットでのgitの有用性を失うことなく、他の人のためにリポジトリをクリーンに保ちます。

ただし、長期ブランチの存在はまれなことです。通常、私の仕事はすべて開発中です。時間がかかりそうな機能（セット）があり、通常の開発スタッフでも作業できるようにする必要がある場合にのみ、LongTermブランチを使用します。一緒にすべき変更のセットだけである場合は、すべてが完了するまでマスターにマージしません。

— コテイル
ソース

「主要な（長期的な）機能では、開発からブランチを作成します」-本番ブランチから新しい機能（開発）ブランチを作成しませんか？Productionブランチは、すぐにリリースできるコードです。

— ロボトロン

いいえ、プロダクションはすでにリリースされており、マスターはプロダクションよりも先であり、開発はマスターよりも先です。注文が既にあるコードで作業していない場合、注文合計に税金を追加するなどの新機能は無意味です。

— coteyr

しかし、あなたが開発者からブランチし、後でマージバックすると、そのブランチ（そしてマスターとプロダクションが後になります）は、ブランチのポイントまで他の人によって行われたすべての開発者の変更を取り入れますか？これらの変更の一部には、QAの承認がない場合があります。おそらく、リリース管理へのさまざまなアプローチについて話していました。

— ロボトロン

はい、そうです、それがポイントです。QAはマスターの特定のSHAでテストしますが、そのためにdevを保持することはできません。

— coteyr

「マスターの特定のSHAでのQAテスト」-> QAは各新機能をスタンドアロンとしてテストしますか？私のチームが直面している典型的なシナリオを実行してみましょう。同じコードベースで2つの長期実行プロジェクトがあるとします。プロジェクトAは先月QAにあり、別の月にQAされます。プロジェクトBは過去6か月間開発中で、現在QAの準備ができています。プロジェクトAはマスターにマージされ、多数の微妙なビジネスルールエラーのために、確実に本番環境に対応していません。プロジェクトBをどのように処理しますか？AとBは、相互作用を確認するために一緒にテストする必要があります（Bはマージ中に競合を引き起こしません）。

— ロボトロン