web-dev-qa-db-ja.com

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

私たちのチームでは、個々の作業単位（ストーリー）に加えて、長期にわたる作業テーマ（エピック）を用意しています。複数の物語が叙事詩を作ります。

従来、各ストーリーには機能ブランチがあり、QAに合格するとマスターブランチにマージされました。ただし、エピックが「機能の完了」と見なされるまで、エピックでの完成したストーリーのリリースは控えたいと思います。 Epic全体が閉じているときにのみ、これらの機能を本番環境にリリースします。さらに、夜間ビルドサーバーがあります。すべての閉じたストーリー（不完全なEpicsの一部を含む）をこの夜間サーバーに自動的に展開します。

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

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

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

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

機能の切り替え または branch-by-abstraction との継続的な統合を使用して、次のことを確認することをお勧めします。

  • すべてのコードが常に統合されている（少なくとも毎日、できればもっと頻繁に）
  • deployedを取得するものは明示的に制御されます。
24
soru

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

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

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

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

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

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

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

準備ができると、テストされたマスターのコミットが本番環境にマージされ、そのブランチから本番環境へのデプロイが行われます。緊急時に行う必要があるHOTFIXは、マスターにマージする必要がない（テストされていない変更が多数ある可能性がある）ことなく、運用ブランチで実行できます。

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

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

単一の変更は数時間以上かかるべきではないというのが私の一般的なルールです。その場合は、小さな変更を加える必要があります。それが巨大な機能（UIの書き換えなど）の場合は、長期的には正常な開発を継続できるようになります。 LongTermブランチは通常ローカルブランチのみですが、開発、マスター、およびプロダクションはリモートブランチです。サブブランチもローカルのみです。これにより、長期間の機能セットでgitの有用性を失うことなく、他のユーザーのためにリポジトリをクリーンに保つことができます。

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

1
coteyr

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

例えば。

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

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

石の発売日が決まっていますD

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

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

ソリューションはより人間的なものです。あなたはあなたのリリース日を逃しました、そしてそれを押し戻す必要があります。

1
Ewan