分岐するかしないか？

最近まで、私の開発ワークフローは次のとおりでした。

1. 製品所有者から機能を入手する
2. ブランチを作成します（機能が1日以上の場合）
3. ブランチに実装する
4. メインブランチからブランチへの変更をマージします（後方マージ中の競合を減らすため）
5. ブランチをメインブランチにマージする

マージに問題があることもありましたが、一般的には気に入っています。

しかし、最近、継続的な統合や継続的な配信などを実践するのが難しくなるため、ブランチを作成しないというアイデアの信者が増えています。 Git、Mercurialなど

質問は、最近のブランチを使用する必要がありますか？

あなたはすべて同じ作業ツリーの外に作業している場合を除き、あなたがしている、あなたがそれをそれらを呼び出すかどうか、枝を使用します。開発者は作業ツリーにチェックアウトするたびに、開発のローカルブランチを個別に作成し、チェックインするたびにマージを行います。ほとんどのチームにとって、質問はブランチを使用するかどうかではなく、質問の数と目的は何ですか？

真に「継続的な」統合を行う唯一の方法は、誰もが同じ作業ツリーで作業することです。そうすれば、変更が他の人に悪影響を与えるかどうかをすぐに知ることができます。明らかに、それは受け入れられません。その「ブランチ」が単にローカルの作業ディレクトリであっても、何かを達成するためには、ブランチである程度の分離が必要です。必要なのは、統合と分離の適切なバランスです。

私の経験では、より多くのブランチを使用すると、統合の程度が向上します。統合は、必要な人と正確に行われ、他のすべての人が必要に応じて関連のない問題をより簡単に分離できるためです。

たとえば、私はビルドで最近導入された3つの統合関連バグを追跡し、「実際の」作業をブロックしていた最後の日を過ごしました。これらのバグを修正する必要のある人々に報告するためにデューデリジェンスを行ったので、作業が続行されるまでそれらが終了するのを待つことになりますか？もちろん違います。これらの変更を元に戻す一時的なローカルブランチを作成したので、アップストリームから最新の変更を受信しながら、安定したベースラインを使用して作業できます。

そのために新しいブランチを作成する機能がなければ、3つのオプションのいずれかになります：中央リポジトリの変更を元に戻す、作業ツリーでそれらを元に戻すパッチを手動で維持し、誤ってチェックインしないようにする、またはそれらのバグが導入される前のバージョンにバックアウトします。最初のオプションは、他の依存関係を壊す可能性があります。2番目のオプションは多くの作業であるため、ほとんどの人は3番目のオプションを選択します。これにより、以前に見つかったバグが修正されるまで、統合作業を行うことができなくなります。

私の例ではプライベートローカルブランチを使用しましたが、共有ブランチにも同じ原則が適用されます。ブランチを共有する場合、5人の他の人が冗長な統合作業を実行する代わりに主要なタスクを続行できる可能性があります。したがって、全体としてより有用な統合作業が実行されます。分岐と継続的インテグレーションの問題は、ブランチの数ではなく、ブランチをマージする頻度です。

問題は、最近ブランチを使用すべきかどうかです。

約半年前、私はその質問に答えるための研究を行うように割り当てられました。調査された参考文献に基づいた概要は以下のとおりです

• どのプロジェクトにも適用できる、一般的に合意された「最良の」分岐戦略はありません
  • ほとんどのリソースは、生産的戦略の選択が特定のプロジェクトの詳細に依存することに同意しているようです
  • サイドノート。上記に基づいて、プロジェクトの分岐戦略への変更は、テスト、測定、およびテストされた他のオプションと比較する必要があるようです。
• 人気のある意見は、Subversionとのマージには多くの努力が必要だということです。SVNとGitを比較したすべての人は、Gitを使用するとマージが非常に簡単になることに注目しています
• 重要な要因は、実稼働リリースがトランクまたはブランチからのものであるかどうかのようです。トランクからprodリリースを行うチーム（これはあまり一般的な方法ではないようです）は、不安定なトランク戦略を使用することを本質的に禁止しています。ブランチから製品リリースを行うチームには、より多くのブランチオプションがあります。
• 人気のある戦略は、安定したトランク、不安定なトランク、開発（統合）ブランチのようです

参照

• http://msdn.microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
  

  ...最良の分岐戦略を決定することは、バランスをとる行為です。生産性の向上とリスクの増加をトレードオフする必要があります。選択した戦略を検証する1つの方法は、変化のシナリオを考慮することです。たとえば、ブランチをシステムアーキテクチャに合わせる場合（たとえば、ブランチはシステムコンポーネントを表す）、アーキテクチャの大幅な変更が予想される場合は、変更のたびにブランチおよび関連するプロセスとポリシーを再構築する必要があります。不適切な分岐戦略を選択すると、プロセスのオーバーヘッドが発生し、統合とリリースのサイクルが長くなり、チーム全体がイライラすることがあります...

• http://www.cmcrossroads.com/bradapp/acme/branching/
  

  ...頻繁に段階的に統合することは成功の道しるべの1つであり、その不在は多くの場合失敗の特徴です。現在のプロジェクト管理方法では、厳密なウォーターフォールモデルを回避し、反復/インクリメンタル開発および進化的デリバリーのスパイラルのようなモデルを採用する傾向があります。Merge Early、Often、およびそのバリアントのような漸進的統合戦略は、リスクに対応する時間があれば、ライフサイクルの早い段階でリスクを洗い流そうとするリスク管理の一形態です。統合間のリズムの規則性は、[Booch]、[McCarthy]、および[McConnell]によって、プロジェクトの健全性の主要な指標（「パルス」または「ハートビート」など）として見られます。  
   
  早期かつ頻繁な統合は、リスクをより早く、より小さな「チャンク」で具体化するだけでなく、チームメイト間の変更を伝達します...

• http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
  

  ...ほとんどのソース管理システムでは、パフォーマンスの問題がまったくない状態で何百ものブランチを作成できます。本当に心配する必要があるのは、すべてのブランチを追跡することの精神的なオーバーヘッドです...ブランチは複雑な獣です。分岐する方法は数十ありますが、あなたがそれを正しく行っているのか間違っているのかを本当に誰もあなたに伝えることはできません...

• http://www.lostechies.com/blogs/derickbailey/archive/2010/02/24/branching-strategies-when-to-branch-and-merge.aspx
  

  ...コードを分岐する際に考慮すべきシステムの多くの側面があります...最後に、目標は、コードが記述されているコンテキストにサンドボックスを提供することです。利用可能なオプションを理解し、各オプションが手元の状況に最も適している場合、これらのオプションのコストは、分岐する方法とタイミングを決定するのに役立ちます...

• http://www.snuffybear.com/ucm_branch.htm
  ここにリストされている他の参考文献を考えると、「この記事ではソフトウェアエンジニアリングプロジェクトで使用される3つの主要な分岐モデルについて説明しています」という主張は正当化されません。使用されている用語は広く見られません（EFIX、Model-1,2,3など）。

• http://svn.haxx.se/users/archive-2007-10/att-0101/SCMBranchingModels-talkback.pdf
  リファレンスには、分岐戦略の伝達が困難な興味深い例が示されています。

• http://simpleprogrammer.com/2010/06/04/simple-branching-strategy-part-1-back-to-basics/
  ...シンプルに保ちます。私の意見では、トランクの外で直接作業することが最善のアプローチです。  
   
  画面に実際に入力すると、ほとんど異端のように聞こえますが、しばらくお待ちください。これがアジャイルプロセスに不可欠である理由を説明するだけでなく、その方法を説明します。それを機能させるために...  
   
  ...もし私が一つの堅実な議論に基づいて推論をしなければならなかったなら、それは継続的統合の価値でしょう。過去のCIの価値とベストプラクティスについてブログに投稿しました。私はCIのかなり大きな支持者です...  
   
  ...あなたは本当にここで自分自身に質問をする必要があります。「あなたは、複雑な分岐を行うと、よりシンプルな戦略の上に存在していない実際の値が得られた戦略をマージから被るれているすべてのオーバーヘッドがか？」...  
   
  ..過去に私が効果的に使用してきた戦略と、時間の経過とともに発展してきた戦略。ここで簡単にまとめます。

  • 誰もがトランクから離れて働いています。
  • コードをリリースすると分岐します。
  • すでにリリースされたコードのバグ修正を作成する必要がある場合は、リリースを分岐します。
  • プロトタイプのブランチ。
    ...
    • http://simpleprogrammer.com/2010/06/07/simple-branching-strategy-part-2-implementation/
      ...かなり詳細なウォークスルー...

• http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
  最後に、理想的な分岐およびマージ戦略がないことを忘れないでください。独自の開発環境に大きく依存します...

• http://blog.perforce.com/blog/?cat=62
  ...最悪のシナリオは、自動化されたマージの結果が間違っているが「OK」をコンパイルして過去に潜入する「セマンティックマージ」問題を導入することです。テスト、おそらくは目に見えるバグになるほど長く生き延びます。ほら！  
   
  検出をより長く逃れることができるため、けがにin辱を加えます。セマンティックマージの問題は後で変更するのが難しくなります。変更は、変更を行った開発者の頭の中ではもはや新鮮で​​はないからです。（通常、変更が行われた後すぐにマージするのが最善です。理想的なのは、それが実用的な場合は変更を行った開発者です）...

  • http://blog.perforce.com/blog/?p=1635
    推奨ポリシーは、http ：//www.infoq.com/articles/agile-version-control#q11およびhttpで定義されているように、開発ブランチに似ていることに注意してください。：//msdn.microsoft.com/en-us/library/bb668955.aspx
  • プロモーションモデルの説明：http : //www.perforce.com/perforce/papers/life.html

• https://stackoverflow.com/questions/34975/branching-strategies
  コミュニティメンバーは、さまざまな分岐戦略を使用して、さまざまなプロジェクトでさまざまな経験を共有しています。「最良」または「最悪」について合意されたコンセンサスはありません。

  • http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
    「クラシック」リーディング- メインラインモデル、コードラインなどの用語の説明

• http://www.stickyminds.com/s.asp?F=S16454_COL_2
  基本的にはhttp://oreilly.com/catalog/practicalperforce/chapter/ch07.pdfに示されている内容の簡単な要約

  • http://www.stickyminds.com/s.asp?F=S16511_COL_2
    ...分岐するタイミングと方法を決定するための3つの一般的なアプローチがあります。
    • 「機能が完全」になったらリリースブランチを作成し、このコード行の土壇場での問題の修正を計画します。この場合、リリースブランチは実際には「リリース準備コード行」です。ソフトウェア構成管理パターンで説明されているように、まだ作業が残っていると予想されるためです。
    • 作業スタイルを変更して、最終的な統合作業を回避し、アクティブな開発ラインで作業します。
    • タスクブランチを作成し、リリースの完了後にその作業をアクティブな開発ラインにマージすることにより、新しい作業に分岐します。
      ...分岐の理由は、リリースの最後にコードを分離して、安定させることです。分岐による分離は、製品がリリースされる前にパラレルストリームを維持するための追加コストが発生するという品質問題を隠してしまうことがよくあります。分岐は簡単です。むしろ、ブランチ間の変更がどのように流れるかを理解することのマージと認知オーバーヘッドであるため、ブランチとマージのコストを最小限に抑えるプロセスを選択することが重要です...

• http://nvie.com/posts/a-successful-git-branching-model/ Git指向の戦略。
  ... Origin / masterは、HEADのソースコードが常に生産準備完了状態を反映するメインブランチであると見なします。  origin / developはメインブランチであり、HEADのソースコードは常に、次のリリースで提供される最新の開発変更の状態を反映していると
   
  考えています。これを「統合ブランチ」と呼ぶ人もいます。これは、自動ナイトリービルドのビルド元です。

  • http://www.infoq.com/articles/agile-version-control#q11およびhttp://msdn.microsoft.com/en-us/library/bb668955.aspxで定義されている開発ブランチ戦略にやや似ている

• http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
  ...プロジェクトポリシーは、機能ブランチを作成することが適切である正確な時期に関して大きく異なります。いくつかのプロジェクトは、すべての機能ブランチを使用することはありません：へのコミット/トランクは自由のために、すべてのです。このシステムの利点は、単純であるということです。分岐やマージについて学ぶ必要はありません。欠点は、トランクコードが不安定または使用できないことが多いことです。その他のプロジェクトは、極端に枝を使用します。何の変更がされ、これまで直接トランクにコミットしていません。最も些細な変更でさえ、短命のブランチで作成され、慎重にレビューされ、トランクにマージされます。その後、ブランチが削除されます。このシステムは、常に非常に安定した使用可能なトランクを保証しますが、多大なコストがかかりますプロセスのオーバーヘッド。  
   
  ほとんどのプロジェクトでは、中道的なアプローチを採用しています。彼らは一般に、/ trunkが常に回帰テストをコンパイルして合格することを主張します。機能ブランチが必要になるのは、変更に不安定なコミットが多数必要な場合のみです。いい経験則はこの質問をすることです：開発者が数日間単独で働いてから一度に大きな変更をコミットした場合（/ trunkが不安定にならないように）、レビューするには大きすぎる変更でしょうか？その質問に対する答えが「はい」の場合、機能ブランチで変更を開発する必要があります。開発者が増分変更をブランチにコミットするとき、それらはピアによって簡単にレビューできます。  
   
  最後に、作業の進行に合わせて機能ブランチをトランクと「同期」状態に保つ最善の方法の問題があります。前に述べたように、数週間または数か月間ブランチで作業することには大きなリスクがあります。2つの開発ラインが大きく異なるため、ブランチをトランクにマージしようとする悪夢になる可能性があります。  
   
  この状況は、トランクの変更をブランチに定期的にマージすることで回避するのが最善です。ポリシーを作成します。1週間に1回、先週分のトランクの変更をブランチにマージします...

• http://thedesignspace.net/MT2archives/000680.html
  ... Eclipse CVSチュートリアルのこのセクションは、Eclipse WebサイトでのPaul Glezenの記事：Eclipse and CVSでの分岐に基づいており、 EPLライセンス。私が彼のバージョンに加えた変更は、主にステップバイステップの画像と説明でそれを拡張し、初心者とデザイナーがよりアクセスしやすいように、私自身の初心者チュートリアルと統合することです。経験豊富な開発者は、おそらくポールのバージョンから作業することを好むでしょう...

  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article1.html
  • http://www.eclipse.org/articles/article.php?file=Article-BranchingWithEclipseAndCVS/article2.html

• http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
  ...一般的な分岐モデルの一部を次に示します。  

  1. ブランチごとのモデル：最も一般的なブランチ戦略の1つは、ブランチを製品リリースに合わせることです。ブランチには、1つのリリースのすべてのソフトウェア開発資産が保持されます。更新は、あるリリースから別のリリースにマージする必要がある場合がありますが、通常はマージされません。リリースが廃止されると、ブランチは廃止されます。  
  2. プロモーションごとのブランチ：もう1つの非常に一般的なアプローチは、ブランチをソフトウェア資産プロモーションレベルに合わせることです。特定の開発バージョンはテストブランチに分岐され、すべての統合およびシステムテストが実行されます。テストを完了すると、ソフトウェア開発資産は実稼働ブランチに分岐し、最終的に展開されます。  
  3. タスクごとのブランチ：タスク（またはアクティビティ）の重複と生産性の損失を回避するために、それらを別のブランチに分離できます。これらは、タスクが完了するとすぐにマージする必要がある短期ブランチであることに注意してください。さもなければ、必要なマージ作業は、そもそもブランチを作成する生産性のメリットを超える可能性があります。  
  4. コンポーネントごとのブランチ：各ブランチをシステムアーキテクチャに合わせることができます。この戦略では、個々のコンポーネント（またはサブシステム）から分岐します。次に、コンポーネントを開発する各チームは、統合ブランチとして機能する開発ラインにコードをマージするタイミングを決定します。この戦略は、システムアーキテクチャが整っていて、個々のコンポーネントに明確に定義されたインターフェイスがある場合にうまく機能します。ブランチ上でコンポーネントを開発するという事実により、ソフトウェア開発資産をよりきめ細かく制御できます。  
  5. 技術ごとの分岐：システムアーキテクチャに合わせた別の分岐戦略。この場合、ブランチはテクノロジープラットフォームに合わせて調整されます。共通コードは別のブランチで管理されます。ブランチ上で管理されるソフトウェア開発資産のユニークな性質により、それらはおそらくマージされません...

• http://msdn.microsoft.com/en-us/library/bb668955.aspx
  ...分岐およびマージのガイドラインの概要については、このガイドの「ソース管理ガイドライン」の分岐およびマージのガイドラインを参照してください。...分岐するときは、次のことを考慮してください。

  • 開発チームが同じファイルセットを同時に操作する必要がない限り、分岐しないでください。これについて確信が持てない場合は、ビルドにラベルを付けて、後でそのビルドからブランチを作成できます。特にブランチ間に大きな変更がある場合、ブランチのマージは時間がかかり複雑になる可能性があります。
  • 階層全体ではなく、階層に沿って（分岐ツリーの上下に）マージするだけで済むように、分岐ツリーを構築します。階層全体に分岐するには、ベースレスマージを使用する必要があります。これには、より多くの手動の競合解決が必要です。
  • ブランチ階層は、ブランチの親とブランチの子に基づいており、ディスク上のソースコードの物理構造とは異なる場合があります。マージを計画するときは、ディスク上の物理構造ではなく、論理的な分岐構造に留意してください。
  • 深く分岐しすぎないでください。各マージの実行と競合の解決には時間がかかるため、分岐構造が深いと、子ブランチの変更がメインブランチに反映されるまでに非常に長い時間がかかる場合があります。これは、プロジェクトのスケジュールに悪影響を及ぼす可能性があり、バグを修正する時間が長くなります。
  • 高レベルで分岐し、構成ファイルとソースファイルを含めます。
  • 時間の経過とともに分岐構造を進化させます。
  • マージでは、1人以上の開発者がマージを実行して競合を解決する必要があります。マージされたソースは、ビルドを不安定にする可能性のある悪いマージ決定を行うことは珍しくないため、徹底的にテストする必要があります。
  • ブランチ階層全体でのマージは特に難しく、そうでなければ自動的に処理できる多くの競合を手動で処理する必要があります。  
    ブランチを作成するかどうかの決定は、競合をリアルタイムでマージするコストがブランチ間の競合をマージするオーバーヘッドコストよりも高いかどうかにまで減らすことができます...

• http://kashfarooq.wordpress.com/2009/11/23/bazaar-branching-strategy-with-a-subversion-trunk/

  • http://kashfarooq.wordpress.com/2010/12/16/bazaar-branching-strategy-with-a-subversion-trunk-revised/
  • http://kashfarooq.wordpress.com/2009/11/02/using-bazaar-feature-branches-with-a-subversion-trunk/
  • http://kashfarooq.wordpress.com/2009/09/08/bazaar-or-git-moving-away-from-subversion/
    ...これらのSubversionの苦情はおなじみですか？
    • 「アップデートを実行する必要がある」とランダムに指示されます。その後、更新を行います-完了するには時間がかかります。そして最後に、ダウンロードする必要のある変更はなかったことがわかります。
    • 「クリーンアップを実行する必要がある」とランダムに指示されます。
    • 巨大なマージの問題があります。たとえば、ReSharperを使用してクラスの名前を変更すると、他の人がそのクラスをその間に更新しました。その後、恐ろしいツリーの競合エラー（震え）が表示されます。さらに悪いことに、名前空間とフォルダ全体の名前を変更します（ダブルシャダー）。今、あなたは本当に痛みの世界にいる。
    • あなたのマージはますます手作業になる傾向があります。Subversionには手がかりがないため、WinMergeを頻繁に使用する必要があります。
    • Tortoiseが更新/変更/何かをチェックするのをしばしば待っています。  
       
      USBペンドライブにSubversionリポジトリがあります。私はツリーの競合を取得し、それと問題をマージし、私は唯一のユーザーです！  
       
      主な問題はマージです...  
       
  • 「subversion sucks」はおなじみの音です。ジョエルとライナスを聴く時間？

• http://social.msdn.microsoft.com/Forums/en/tfsversioncontrol/thread/f127676c-8f05-410c-9a30-0eb43a26a9fa
  進化するシステムの場合のリリース分離ブランチ戦略のベストプラクティスに関する議論。

• http://branchingguidance.codeplex.com/「Microsoft
  Team Foundation Server Branching Guidance」-さまざまなプロジェクトに合わせた推奨事項を含む巨大で詳細なドキュメント：HTMLバージョンはこちら。マイクロソフトが分岐戦略に対する万能アプローチを信じていないことを証明します。

• https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration
  継続的な統合を行う場合に使用する最適な分岐戦略は何ですか？...答えは、チームの規模とソース管理の品質、および複雑な変更セットを正しくマージする能力に依存します...

  • http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ Hudson / Jenkinsでの具体的な経験に基づいた、継続的な統合を伴う分岐相互作用の詳細な分析-いくつかの有用なリファレンス
    ..私の最大の発見は、CIは頻繁にフィードバックをコミット、プッシュ、取得することです（つまり、CIクラスターはワークステーションが同じ時間内にあなたに決して与えることができないフィードバックを提供する）が、真の純粋なCIには実際にもう1つの要件があることです—チームが同じベースラインで作業する必要があること...
    使用される材料
    • 複数ブランチのベストプラクティス -Jenkinsリストに投稿する
    • いくつかのジョブが重複することなくそれぞれで実行される複数のブランチを処理することは可能ですか？ Jenkinsリストに投稿してください
    • ブランチを使用した並列開発 -Jenkinsリストへの投稿
    • Hudsonジョブを自動的に構成または作成する – stackoverflow.com
    • 複数のブランチ開発との継続的な統合 – stackoverflow.com
    • 継続的インテグレーションでの複数のブランチの処理 – stackoverflow.com
    • 継続的インテグレーション– Martin Fowler
    • 継続的インテグレーション–ウィキペディア

• http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
  ... CVSとSVNは、ブランチ/マージ戦略全体を思いとどまらせていました... ...単純なルール：実装するすべての新機能またはバグ修正のためにタスクブランチを作成します... SVN / CVSユーザーにとってはやり過ぎのように聞こえますが、最新のSCMを使用するとすぐにブランチを作成できるため、実際のオーバーヘッドはありません。  
   
  重要な注意：注意深く見ると、タスクブランチを金持ちのチェンジリストとして使用することについて話していることがわかります...

• http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_proj.doc/c_bntr_plnbrstrat.htm
  ...分岐ポリシーは開発の影響を受けますプロジェクトの目的であり、コードベースの進化を制御するメカニズムを提供します。分岐ポリシーには、Rational ClearCaseのバージョン管理を使用する組織と同数のバリエーションがあります。しかし、ベストプラクティスの一般的な順守を反映する類似点もあります...

• http://blogs.open.collab.net/svn/2007/11/branching-strat.html
  ... Subversionモデル（またはより正確な一般的なオープンソースモデル）は、不安定なトランクモデルで示されています。 。

• http://en.wikipedia.org/wiki/Trunk_%28software%29
  ソフトウェア開発の分野では、トランクはリビジョン管理下にあるファイルツリーの名前のないブランチ（バージョン）を指します。トランクは通常、開発が進行するプロジェクトのベースとなることを意図しています。開発者がトランクのみで作業している場合、プロジェクトの最新バージョンが常に含まれていますが、最も不安定なバージョンである可能性もあります。別のアプローチは、ブランチをトランクから分割し、そのブランチに変更を実装し、ブランチが安定して動作していることが証明されたときに変更をトランクにマージすることです。開発モードとコミットに依存トランクには、最も安定したバージョン、最も安定性の低いバージョン、または中間バージョンが含まれる場合があります。  
   
  多くの場合、主要な開発者の作業はトランクで行われ、安定バージョンが分岐され、時折バグ修正がブランチからトランクにマージされます。将来のバージョンの開発が非トランクブランチで行われる場合、通常、頻繁に変更されないプロジェクト、またはトランクに組み込む準備が整うまで変更の開発に長い時間がかかると予想されるプロジェクトに対して行われます。 。

• http://www.mcqueeney.com/roller/page/tom/20060919
  ...これらは、CollabNetが2006年8月30日に実施したSubversionのベストプラクティスに関するウェビナーのメモです。... 2つの組織戦略：不安定なトランクと安定したトランク... ...可能な場合は不安定なトランクを優先する...

• https://stackoverflow.com/questions/153812/subversion-is-trunk-really-the-best-place-for-the-main-development
  SVNでは、トランクはメイン開発に推奨される場所であり、この規約を使用します私のすべてのプロジェクトに。ただし、これは、トランクが時々不安定であるか壊れていることを意味します... ... / branch / devのようなブランチで「ワイルドな開発」を行い、ビルドが合理的に行われた場合にのみトランクにマージする方が良いでしょう固体？

  • ...トランクは、進行中の開発が行われる場所です。誰もがコミットする前に変更をテストしている場合、「壊れた」コードに問題はないはずです。良い経験則は、変更をコーディングした後に更新（リポジトリからすべての最新コードを取得）することです。次に、ユニットテストをビルドして実行します。すべてがビルドされて動作する場合は、チェックインしてください...
  • ... Nopeトランクは最適な場所ではありません。私たちの組織では、常にこのアプローチに従います。トランクにはリリースコードが含まれているため、常にコンパイルされます。新しいリリース/マイルストーンごとに、新しいブランチを開きます。開発者がアイテムを所有するときはいつでも、彼/彼女はこのリリースブランチへの新しいブランチを作成し、それをテストした後にのみリリースブランチにマージします。リリースブランチはシステムテスト後にトランクにマージされます...

• http://blog.yclian.com/2009/03/working-on-branches-and-stable-trunk.html
  ...私は以前トランクで働いていました。なぜなら、私が取り組んだすべてのプロジェクトで、唯一の開発者またはチームは、すべてのコードチェックインがローカルテストに合格するようにしました。それ以外の場合、バグ修正用のブランチ（新機能用の大きなコードなど）を作成しました。  
   
  約2か月前、Kamalと短いgitセッションを行い、彼はstory / branchのアイデアを共有しました。そして、私のチームがより多くの開発者で成長し始めたとき、私はより多くの分岐を奨励する必要性を感じ、今ではこれがルールになっています。CIセットアップで定義された自動テストを含むプロジェクトの場合、安定したトランクが保証され、このプラクティスはそれに非常に適合します。  
   
  gitではなくSubversionを使用します。これが私たちが始めた方法であり、今でも（ほとんどの場合）それに満足しているからです...

• http://www.ericsink.com/scm/scm_branches.html
  これは、ソース管理、バージョン管理、構成管理に関するベストプラクティスガイドであるSource Control HOWTOと呼ばれるオンラインブックの一部です  
   
  ... ... Eric's Preferred Branching練習...「基本的に不安定な」トランクを維持します。トランクでアクティブな開発を行います。リリースに近づくと安定性が向上します。出荷後、メンテナンスブランチを作成し、常に非常に安定した状態に保ちます  
   
  ... ... 次の章では、ブランチのマージのトピックを掘り下げます...

• http://marc.info/?l=forrest-dev&m=112504297928196&w=2 Apache Forrestプロジェクトの
  分岐戦略を議論するスレッドのメールを開始する

  • 現在、プロジェクトはリリースブランチで不安定なトランクモデルを使用しているように見えることに注意してください。
  • 「開発作業はSVNのトランクで行われます... forrest_07_branchなど、SVNの「リリースブランチ」があります。」（プロジェクトのガイドライン）
  • 「リリース候補パッケージのビルド... 17. SVNでのメンテナンスブランチの作成...」（リリース方法）

• O'Reilly CVS分岐ドキュメント：http :
  //commons.oreilly.com/wiki/index.php/Essential_CVS/Using_CVS/Tagging_and_Branching#Basically_stable
  

  • ...基本的に安定した分岐の哲学では、トランクには常にリリースの準備が整っているプロジェクトデータが含まれている必要があると述べています... ...この哲学のより寛大なバリエーションにより、開発者の単体テストに合格したものはすべて、トランク。このようなリラックスしたアプローチでは、リリース候補者が分岐して、公開前に完全なQA分析を行う必要があります...
  • ...基本的に不安定な哲学では、安定性に関係なくトランクに最新のコードを含める必要があり、リリース候補はQAに分岐する必要があると述べています。
     
     
    ...さらに寛大なバリエーションにより、実験的なコードの分岐、リファクタリング、およびその他の特殊なケースのコードも可能です。ブランチのトランクへのマージは、ブランチのマネージャーによって行われます。...
    • 上記のリソースは、私が実行した検索のいずれにも表示されませんでした（CVS関連のガイドラインはもはや一般的ではありませんか？）

• SCM（PERFORCEの記事）のベストプラクティスで
  http://www.perforce.com/perforce/papers/bestpractices.html
  ... 6つのSCMの展開の一般的な領域、およびそれらの各領域内のいくつかの粗粒のベストプラクティス。次の章では、各項目について説明します...
  ワークスペース、コードライン、分岐、変更の伝播、ビルド、プロセス ...

複数のチームが異なる機能を同時に使用している場合、分岐を省略する方法はありません。他のチームが未完成の機能を取得できないように、チームメンバーとコードを共有する（部分的に実装する）必要があります。

ブランチはそれを達成する最も簡単な方法です。

ブランチのライフサイクルを短くして、同時に2つのブランチの同じモジュールで作業しないようにすることは良いことですが、競合やマージの問題は発生しません。

しかし最近、継続的な統合、継続的な配信などを実践するのが難しくなるため、ブランチを作成しないというアイデアの支持者が増えています。

それでは、継続的インテグレーション、継続的デリバリーなどを具体的に実践するのがより難しくなりますか？

そうでなければ、あなたの働き方を変える理由はないと思います。

もちろん、何が起こっているのか、現在のベストプラクティスがどのように進化するのかをフォローすることは良い習慣です。しかし、X（および/またはYおよび/またはZ）がもはや流行ではないと言ったからといって、プロセス/ツール/その他を放棄する必要はないと思います:-)

なんと面白い答えのセット。20年以上、私はブランチをささいな使用にとどめた会社で働いたことは一度もありません（一般的にブランチリリースのみ）。

私が働いたほとんどの場所は、かなり迅速なチェックインと衝突の迅速な検出/解決に依存しています。アジャイル手法は、両方の当事者がコードの一部について積極的に考えている間に問題に気付くと、より迅速に問題を解決できることを教えています。

一方、私はgitをあまり使用していません。おそらく、これらの回答に影響を与えたのはgitタグを含めることです。

はい、ブランチを使用して（少なくとも中規模の）開発作業を分離する必要があります。「いつ分岐しますか？」を参照してください。

最初にすべての「中間チェックポイントコミット」（ロールバックまたはの場合に問題になる可能性がある）をすべて押しつぶす場合、問題は早送りマージ（別のマージ履歴内にブランチ履歴を含む）を使用することですgit bisect。
「Gitのワークフローを理解する」を参照してください。プライベートブランチ（プッシュされることを意図していません）とパブリックブランチを区別します。 。
「gitがデフォルトで早送りマージを使用する理由」も参照してください。

絶対にブランチを使用する必要があります。それには多くの長所があります。

• HDの障害、ラップトップの紛失などにより作業を失うことが心配で、メインCIが破損しない場合は、作業中に作業をチェックインできます。
• CIを引き続き実行できます。ブランチを監視するには、独自のローカルCIをセットアップするだけです。
• フィーチャが突然保留になった場合（それが起こらない場合）、そのまま駐車できます。

難しすぎることは言い訳にはなりません。それを正しく行うには常により多くの努力が必要です。

2つのチームがそれぞれのブランチで作業している場合、両方のチームがmasterブランチを統合しても、他のチームの変更は表示されません。つまり、開発ブランチがバラバラになり、一方のチームがに統合されたmaster場合、もう一方のチームは多くの変更をリベースする必要があります。

したがって、機能のブランチがある場合でも、すべてのリファクタリングの「バックポート」をマスターブランチに作成し、新しい機能のブランチのみを保持することをお勧めします。

• バックポートリファクタリング

機能スイッチを使用して、まだ運用されていない新しい未テストの機能を無効にする方が簡単な場合があると思います。そうすれば、他のすべてのチームが変更を認識し、ビッグバンマージを行う必要がなくなります。

• 機能スイッチを使用する

私たちはこれを（もう一度）経験しました。最初に、GIT / SVNの討論全体が行われ、それが一般的な分岐戦略につながりました。

大企業はすべてトランクベースの戦略を使用しており、全員が同じブランチで作業し、そのブランチからビルドと継続的な統合が行われます。競合の回避は、コードのモジュール化、機能の切り替え、および巧妙なツールを使用して行われます。これは難しいように聞こえます。しかし、この議論をしているのは、分岐に関する人々の空想の犠牲になったからです。ここでは、Sarbanes-oxleyに完全に準拠したプロモーション分岐メカニズムを備えたInsert SCMツールを使用するという主張もありますが、それはすべて素晴らしいです。彼らは嘘をついているか、自分自身をだましているか、あなたと同じ規模のシステムで働いていないかのどちらかです。

分岐とマージは困難です。特に、定期的に考えを変え、ロールバックなどを要求するビジネスがある場合

この文はあなたの命を救うかもしれません： SCMにあるものはあなたの構築されたアーティファクトにあるものと同じではありません！

分岐に問題がある場合は、SCMを誤用しているためです。私たちは皆何年もやっています。SCMを使用して最終ビルドの内容を決定するシステムが用意されています。

それはSCMの仕事ではありません。SCMは、美化されたファイルサーバーです。SCMのどのファイルをビルドに入れるかを決定する作業は、ビルドツールに属します。

モジュールAは現在作業中であり、毎週のリリースに入ります。モジュールBはモジュールAですが、プロジェクトXが含まれており、同じブランチで作業中ですが、リリースに組み込まれていません。将来のある時点で、プロジェクトXをリリースしたいので、ビルドツールにモジュールAの挿入を停止し、モジュールBの挿入を開始するように指示します。

これについては多くの泣き声があります。どのような不幸、そして一般的なハウリング。これは、どんなに巧妙であっても、ファイルリポジトリのような単純なものを取り巻く感情レベルです。

しかし、あなたの答えがあります。

ブランチの主な問題は、開発が完了したときにメインブランチにマージするのが難しいことです。マージは手動でエラーが発生しやすいプロセスになる可能性があるため、ほとんどの場合は回避する必要があります。

私が分岐することを好むいくつかの注目すべき例外は、大規模なリファクタリング、スプリントの開発に時間がかかる巨大な機能、またはそのスプリントの大部分の間に他の機能の開発を妨害する破壊的な機能です。

この種のブランチスキームをお勧めします。

リリース-テスト-開発

次に、開発から、開発者および/または機能ごとに分岐します。

開発者はそれぞれ、定期的に-理想的には毎日（コンパイルが提供されている場合）開発ブランチと遊ぶ、マージする、そして開発ブランチにマージするブランチを持っています。

この種のスキームは、同じコードベースの多くの開発者と複数のプロジェクトで非常にうまく機能します。

ブランチを使用しますが、機能の詳細レベルでは使用しません。各スプリントにブランチを使用します。本質的に分岐することは、フィーチャまたはスプリントレイヤーのSOCの概念をシミュレートするため、悪いことではありません。どのブランチがどの機能またはスプリントに属しているかを簡単に認識して管理できます。

私見、そして答えはYESです。分岐を使用する必要があります。

私の組織のプロセスは、ブランチと（少し似たようなプロセスの）継続的な統合を広範に使用しています。

高レベルのビューでは、開発者はメインラインとのマージについてあまり心配せず、ブランチにコミットするだけです。（半）自動化されたプロセスは、メインラインに入る予定の機能をチェックし、それらのブランチをマージして製品をビルドします。ビルドツールがマージするブランチを認識するように、問題追跡システムからマージのこのプロセスを実際に統合するため、プロセスが機能します。