分岐するかしないか？
最近まで、私の開発ワークフローは次のとおりでした：
- 製品の所有者から機能を入手する
- ブランチを作成する（機能が1日を超える場合）
- ブランチに実装する
- Mainブランチからmyブランチへの変更をマージします（後方マージ時の競合を減らすため）
- ブランチをマージしてメインブランチに戻す
マージの問題が時々ありましたが、一般的に私はそれが好きでした。
しかし最近では、継続的インテグレーションや継続的デリバリーなどの練習が難しくなるため、ブランチを作らないというアイデアを追う人がますます増えています。また、分散型VCSのバックグラウンドを持ち、 Git、Mercurialなど.
だから問題は今日ブランチを使うべきなのか？
同じ作業ツリーで作業しているのでない限り、ブランチを使用しているとは関係なく、ブランチを使用しています。開発者は自分の作業ツリーにチェックアウトするたびに、開発の個別のローカルブランチを作成し、チェックインするたびにマージを行います。ほとんどのチームでは、問題はブランチではないの場合いくつとです）どんな目的のために？
真に「継続的な」統合を行う唯一の方法は、全員が同じ作業ツリーから作業することです。このようにして、変更が他の人の変更に悪影響を及ぼすかどうかをすぐに知ることができます。明らかに、それは耐えられない。その「ブランチ」がローカルの作業ディレクトリである場合でも、何かを実行するには、ブランチをある程度分離する必要があります。必要なのは、統合と分離の適切なバランスです。
私の経験では、より多くのブランチを使用すると、統合の程度が向上します。統合は、実行する必要がある人と正確に行われ、他の誰もが関連のないものをより簡単に分離できるためです必要に応じて問題。
たとえば、私は最終日、ビルドで最近導入された3つの統合関連のバグを追跡して、「実際の」作業を妨げていました。これらのバグを修正する必要のある人々に報告するために十分な注意を払いましたが、今は彼らが私の仕事を続けるのを終えるまで待つべきですか？もちろん違います。これらの変更を元に戻す一時的なローカルブランチを作成したので、アップストリームから最新の変更を受信しながら、安定したベースラインで作業できます。
その目的で新しいブランチを作成する機能がない場合、私は3つのオプションの1つに削減されます。中央リポジトリの変更を元に戻すか、作業ツリーでそれらを元に戻すパッチを手動で維持し、誤ってチェックインしないようにします。 、またはこれらのバグが導入される前のバージョンに戻します。最初のオプションは、他の依存関係を壊す可能性があります。 2番目のオプションは多くの作業を伴うため、ほとんどの人は3番目のオプションを選択します。これにより、以前に見つかったバグが修正されるまで、基本的にこれ以上の統合作業を行うことができなくなります。
私の例ではプライベートローカルブランチを使用しましたが、同じ原則が共有ブランチにも適用されます。私がブランチを共有している場合、おそらく他の5人が冗長な統合作業を実行する代わりに、主要なタスクを続行できるため、全体としてより有用な統合作業が実行されます。ブランチと継続的インテグレーションの問題は、ブランチの数ではなく、ブランチをマージする頻度です。
問題は、今日ブランチを使用する必要があるかどうかです。
約半年前、私はその質問に答えるための研究を行うように割り当てられました。調査した参考文献に基づく要約は以下のとおりです（以下にリスト）
- どのプロジェクトにも適用できる一般的に合意された「最良の」分岐戦略はありません
- ほとんどのリソースは、生産的な戦略の選択が特定のプロジェクトの詳細に依存することに同意しているようです
- サイドノート。上記に基づいて、プロジェクトの分岐戦略への変更はテスト、測定、およびテストされた他のオプションと比較する必要があるようです
- 一般的な意見では、Subversionとのマージには多くの労力が必要です。 SVNとGitを比較したすべての人は、Gitを使用するとマージが非常に簡単になると指摘しています
- 重要な要素は、製品リリースがトランクとブランチのどちらから発生したかであると思われます。トランクからの製品リリースを行うチーム（あまり一般的な方法ではないようです）は、 unstable trunk 戦略を使用することを基本的に禁止されています。ブランチからの製品リリースを行うチームには、より多くのブランチオプションから選択できます。
- 一般的な戦略は、安定したトランク、不安定なトランク、開発（統合）ブランチのようです
参照
http://msdn.Microsoft.com/en-us/library/aa730834%28v=vs.80%29.aspx
...最適な分岐戦略を決定することは、バランスを取る行為です。生産性の向上とリスクの増大をトレードオフする必要があります。選択した戦略を検証する1つの方法は、変化のシナリオを検討することです。たとえば、ブランチをシステムアーキテクチャに合わせることを決定した場合（たとえば、ブランチはシステムコンポーネントを表す）、アーキテクチャの大幅な変更が予想される場合、ブランチとそれに関連するプロセスとポリシーを再構成する必要が生じる可能性があります。不十分な分岐戦略を選択すると、プロセスのオーバーヘッドと長い統合とリリースサイクルが発生し、チーム全体に不満が生じる可能性があります...
http://www.cmcrossroads.com/bradapp/acme/branching/
...頻繁な段階的な統合は成功の道標の1つであり、その欠如はしばしば失敗の特徴です。現在のプロジェクト管理方法は、厳密なウォーターフォールモデルを回避し、反復/増分開発と進化的配信のスパイラル状モデルを採用する傾向があります。 アーリーアーリーおよびオーテンション などのインクリメンタルインテグレーション戦略とそのバリアントは、リスク管理の1つの形式であり、対応する時間がある場合に、ライフサイクルの早い段階でリスクを洗い流そうとします。統合間のリズムの規則性は、[Booch]、[McCarthy]、および[McConnell]によって、プロジェクトの正常性の主要な指標（「パルス」または「ハートビート」など）と見なされています。
早期かつ頻繁な統合により、リスクがより早く、より小さな「チャンク」に肉付けされるだけでなく、チームメイト間の変更も伝達されます...http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html
...ほとんどのソース管理システムでは、何百ものブランチを作成でき、パフォーマンスの問題はまったくありません。それはあなたが本当に心配する必要があるすべてのそれらのブランチを追跡することのメンタルオーバーヘッドです...ブランチは複雑な獣です。分岐するには何十通りもの方法があり、あなたがそれを正しく行っているのか間違っているのか誰も実際にはあなたに言うことができません...
...コードを分岐する際に考慮すべきシステムの多くの側面があります...最後に、目標は、コードが記述されているコンテキストにサンドボックスを提供することです。利用可能なオプションを理解し、各オプションが当面の状況に最適である場合、および これらのオプションのコスト は、分岐する方法とタイミングを決定するのに役立ちます...
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/
...複雑にしないでおく。私の意見では、トランクから直接作業することが断然最善のアプローチです。
実際に画面に入力すると、ほとんど異端のように聞こえますが、しばらくお待ちください。これがアジャイルプロセスに不可欠だと思う理由を示すだけでなく、それを機能させる方法を紹介します...
... 1つの確固たる議論に基づいて推論を行う必要がある場合、それは継続的統合の価値でしょう。過去に、CIの の価値 および ベストプラクティス についてブログを書きました。私はCIをかなり支持しています...
...実際にここで質問する必要があります。「複雑な分岐とマージの戦略を実行することで生じるすべてのオーバーヘッドが、より単純な戦略では存在しない実際の価値をもたらしていますか？」 ...
...過去に効果的に使用し、時間をかけて開発した戦略。ここで簡単にまとめます。- 誰もがトランクで働いています。
- コードをリリースすると分岐します。
- すでにリリースされたコードのバグ修正を作成する必要がある場合は、リリースを分岐します。
- プロトタイプのブランチ。
...
http://www.codelathe.com/blog/index.php/2009/07/02/a-svn-branching-strategy-that-works/
...最後に、理想的な分岐およびマージ戦略はないことを覚えておいてください。それはあなたのユニークな開発環境にかなり依存します...http://blog.perforce.com/blog/?cat=62
...最悪のシナリオは、「セマンティックマージ」問題が発生することです。この場合、自動マージの結果は正しくありませんが、問題なくコンパイルされ、過去のテストをこっそり行い、おそらく顧客になるまで存続します。 -目に見えるバグ。イーク！
傷害を侮辱に加えると、検出をより長く逃れることができるため、変更を発生させた開発者の頭の中で変更が新鮮ではなくなるため、意味上のマージの問題を後で修正することが難しくなります。 （通常は、変更をすぐにマージするのが最善です。できれば、変更を加えた開発者がそれを実行できる場合は理想的に行います）...https://stackoverflow.com/questions/34975/branching-strategies
コミュニティメンバーは、さまざまな分岐戦略を使用して、さまざまなプロジェクトでさまざまな経験を共有します。 「最良」または「最悪」について合意された合意はありません。- http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
「クラシック」の読み- Mainline Model 、 Codeline などの用語の説明
- 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://www.stickyminds.com/s.asp?F=S16511_COL_2
http://nvie.com/posts/a-successful-git-branching-model/ Git指向の戦略。
... Origin/master は、HEADのソースコードが常に本番準備状態。
Origin/develop をメインブランチと見なし、HEADのソースコードは常に最新の開発状況を反映しています次のリリースでの変更点。これを「統合ブランチ」と呼ぶ人もいます。これは、自動ナイトリービルドがビルドされる場所です...http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html
...プロジェクトポリシーは、機能ブランチを作成するのが適切である場合に関して正確に異なります。一部のプロジェクトでは、機能ブランチをまったく使用しません。/trunk へのコミットは、すべて無料です。このシステムの利点は、シンプルであることです。つまり、分岐やマージについて誰も学ぶ必要はありません。不利な点は、トランクコードが不安定または使用できないことが多いことです。他のプロジェクトは極端にブランチを使用します： ever は変更がトランクに直接コミットされません。最も些細な変更でさえ、存続期間の短いブランチで作成され、慎重に検討され、トランクにマージされます。その後、ブランチは削除されます。このシステムは、非常に安定して使用可能なトランクを常に保証しますが、驚異的なプロセスのオーバーヘッドを犠牲にします。
ほとんどのプロジェクトは中途半端なアプローチを採用しています。彼らは通常、/trunk は常にコンパイルして回帰テストに合格することを要求しています。機能ブランチは、変更に多数の不安定化するコミットが必要な場合にのみ必要です。大体の目安は、この質問をすることです。開発者が何日間も孤立して作業し、大きな変更を一度にコミットした場合（/trunk が不安定にならないように）、レビューするには大きすぎる変更ですか？その質問に対する答えが「はい」の場合、変更は機能ブランチで開発する必要があります。開発者がブランチへの増分変更をコミットすると、それらはピアによって簡単に確認できます。
最後に、作業の進行に合わせて機能ブランチをトランクと「同期」させる最良の方法の問題があります。先に述べたように、ブランチで数週間または数か月作業することには大きなリスクがあります。トランクの変更が流れ込み続け、2つの開発ラインが大きく異なるため、ブランチをトランクにマージしようとする悪夢になる可能性があります。
この状況は、トランクの変更をブランチに定期的にマージすることによって回避するのが最善です。ポリシーを作成します。週に1回、先週分のトランクの変更をブランチにマージします...http://thedesignspace.net/MT2archives/000680.html
... Eclipse CVSチュートリアルのこのセクションは、Eclipse Webサイト上のPaul Glezenの記事に基づいています： Branching with Eclipse and CVS であり、EPLライセンスの条件に基づいて彼の許可を得て使用されています。私が彼のバージョンに加えている変更は、主に段階的な画像と説明でバージョンを拡張し、初心者やデザイナーがアクセスしやすくするために、自分の初心者向けチュートリアルと統合することです。経験豊富な開発者は、おそらくPaulのバージョンから作業することを好むでしょう...http://learnsoftwareprocesses.com/2007/12/29/common-branching-strategies/
...これは、一般的な分岐モデルの一部です。- リリースごとのブランチモデル：最も一般的なブランチ戦略の1つは、ブランチを製品リリースに合わせることです。ブランチは、単一のリリースのすべてのソフトウェア開発資産を保持します。場合によっては、更新をリリース間でマージする必要がありますが、通常はマージされません。リリースが廃止されると、ブランチは廃止されます。
- プロモーションごとのブランチ：別の非常に一般的なアプローチは、ブランチをソフトウェア資産のプロモーションレベルに合わせることです。特定の開発バージョンはTestブランチに分岐され、そこで統合とシステムテストがすべて実行されます。テストを完了すると、ソフトウェア開発資産が本番ブランチに分岐され、最終的に展開されます。
- タスクごとのブランチ：タスク（またはアクティビティ）の重複と生産性の低下を回避するために、タスクを別のブランチに分離できます。これらは、タスクが完了したらすぐにマージする必要がある短期的なブランチであることに注意してください。そうしないと、必要なマージ作業が、最初にブランチを作成する場合の生産性の利点を超える可能性があります。
- コンポーネントごとのブランチ：各ブランチをシステムアーキテクチャに合わせることができます。この戦略では、個々のコンポーネント（またはサブシステム）から分岐します。次に、コンポーネントを開発する各チームは、統合ブランチとして機能する開発ラインにコードをマージするタイミングを決定します。システムアーキテクチャが適切で、個々のコンポーネントに明確に定義されたインターフェイスがある場合、この戦略はうまく機能します。ブランチでコンポーネントを開発することで、ソフトウェア開発資産をよりきめ細かく制御できます。
- テクノロジごとの分岐：システムアーキテクチャに合わせた別の分岐戦略。この場合、ブランチはテクノロジープラットフォームに合わせて調整されます。共通コードは別のブランチで管理されます。ブランチで管理されるソフトウェア開発資産の固有の性質により、おそらくそれらは決してマージされません...
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 version here 。マイクロソフトが分岐戦略に対する万能のアプローチを信じていないことを証明します。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リストへの投稿
- Hudsonジョブを自動的に構成または作成する – stackoverflow.com
- 複数のブランチ開発との継続的な統合 – stackoverflow.com
- 継続的インテグレーションでの複数のブランチの処理 – stackoverflow.com
- 継続的インテグレーション– Martin Fowler
- 継続的インテグレーション–ウィキペディア
- http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/ Hudson/Jenkinsの具体的な経験に基づく、継続的な統合による分岐相互作用の詳細な分析役に立つ参考文献
http://codicesoftware.blogspot.com/2010/03/branching-strategies.html
... CVSとSVNは、完全に分岐/マージすることができなかったため、全体の分岐/マージ戦略を思いとどまらせていました... ...単純なルール：新しい機能やバグ修正のたびにタスクブランチを作成します実装...それはSVN/CVSユーザーにはやり過ぎのように聞こえるかもしれませんが、最近のSCMでは1秒でブランチを作成できるため、実際のオーバーヘッドはありません。
重要な注意：これを注意深く見ると、リッチブランチのチェンジリストとしてタスクブランチを使用することについて話していることがわかります...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
ソフトウェア開発の分野では、 trunk は、 リビジョン管理 の下のファイルツリーの名前のない ブランチ （バージョン）を指します。トランクは通常、開発が進行するプロジェクトのベースになることを意図しています。開発者が専らトランクで作業している場合は、常に最新のプロジェクトの最新バージョンが含まれていますが、最も不安定なバージョンである可能性もあります。別のアプローチは、ブランチをトランクから分割し、そのブランチに変更を実装し、ブランチが安定して機能していることが判明したら、変更をトランクにマージすることです。開発モードと commit ポリシーに応じて、トランクには最も安定したバージョン、最も安定していないバージョン、またはその中間のバージョンが含まれる場合があります。
多くの場合、主な開発者の作業はトランクで行われ、安定バージョンは分岐され、時折バグ修正がブランチからトランクにマージされます。将来のバージョンの開発が非トランクブランチで行われる場合、通常、頻繁に変更されないプロジェクト、またはトランクに組み込む準備ができるまで変更の開発に長い時間がかかることが予想される場合に行われます。 。http://www.mcqueeney.com/roller/page/tom/20060919
...これらは、2006年8月30日にCollabNetによって実施された、 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か月前、私はカマルとの短いgitセッションをしていて、彼は ストーリー/ブランチ のアイデアを私に教えてくれました。そして、私のチームがより多くの開発者と共に成長し始めたとき、私はより多くの分岐を奨励する必要性を感じ、そして今やこれはルールになっています。 CIのセットアップで定義された自動テストのプロジェクトでは、安定したトランクが保証され、このプラクティスはそれに非常によく適合します。
私たちはgitを使用していませんが、Subversionを使用しています。これは、私たちが始めた方法であり、今でも（ほとんどの場合）それに慣れているためです...http://www.ericsink.com/scm/scm_branches.html
これは、 ソース管理HOWTO と呼ばれるオンラインブックの一部であり、ソース管理、バージョン管理、および構成管理に関するベストプラクティスガイドです...
...エリックの優先分岐の実践...「基本的に不安定な」トランクを維持します。トランクで積極的な開発を行います。リリースに近づくにつれて、安定性が向上します。出荷後、メンテナンスブランチを作成し、常に非常に安定した状態に保ちます...
... 次の章で ブランチのマージのトピックを掘り下げます...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
... SCM展開の6つの一般的な領域と、それらの各領域内のいくつかの大まかなベストプラクティス。次の章では、各項目について説明します...
ワークスペース、コードライン、分岐、変更の伝達、ビルド、プロセス...
複数のチームが同時に異なる機能に取り組んでいる場合、分岐を省略する方法はありません。コードを（部分的に実装された）チームメンバーと共有して、他のチームが完成していない機能を取得できないようにする必要があります。
ブランチはそれを達成する最も簡単な方法です。
ブランチのライフサイクルを短くし、2つのブランチで同じモジュールを同時に操作しないようにするのは良いことですが、競合やマージの問題は発生しません。
しかし、最近では、継続的インテグレーション、継続的デリバリーなどを実践することがより困難になるため、ブランチを作成しないというアイデアの信者がますます増えています。
まあそれは継続的な統合、継続的なデリバリーなどを実践することをより難しくしますあなたのために具体的に？
そうでなければ、私はあなたの働き方を変える理由はないと思います。
もちろん、何が起こっているのか、現在のベストプラクティスがどのように進化するのかをフォローすることは良い習慣です。しかし、X（および/またはYおよび/またはZ）がもはや流行していないと言ったからといって、プロセス/ツール/何も放棄する必要はないと思います:-)
興味深い答えのセットです。 20年以上の間、私は（通常はリリースをブランチするために）ブランチをささいな以上に使用する会社で働いたことはありません。
私がこれまでに取り組んだほとんどの場所は、かなり迅速なチェックインと衝突の迅速な検出/解決に依存しています-アジャイル方法論は、両方の当事者がそのコードの部分について積極的に考えているときに問題に気づいた場合、問題をより迅速に解決できることを教えています。
一方、私はgitをあまり使用していないため、これらの回答に影響を与えたのはgitタグが含まれているためと考えられます。ブランチ/マージは非常に簡単なので、gitで指定されていることを理解しています。
はい、ブランチを使用して（少なくとも中程度の）開発作業を分離する必要があります。 「 いつ分岐すべきか 」を参照してください。
最初にすべての「中間チェックポイントコミット」（ロールバックまたはgit bisectの場合に問題になる可能性があります）を押しつぶす場合、問題は早送りマージ（別のマージ内にブランチ履歴を含む）を使用することです。
提供されているffマージ（早送りマージ）によって完了するプライベートブランチ（プッシュするためではない）とパブリックブランチを区別するために、「 Gitワークフローの理解 」を参照してください。マージするブランチ内で必要なクリーンアップを行うこと。
「 デフォルトでgitが早送りマージを使用する理由 」も参照してください。
これを（もう一度）行ったところです。最初に、全体的なGIT/SVNの議論がありました。
大企業はすべて、トランクベースの戦略を使用しており、全員が同じブランチで作業し、そのブランチからビルドと継続的な統合が行われます。競合を回避するには、コードのモジュール化、機能の切り替え、賢いツールを使用します。これは難しいですね。しかし、もしあなたがこの議論をしているなら、それはあなたが分岐についての人々の空想の犠牲になったからです。 ここにSCMツールを挿入を完全にsarbanes-oxley準拠のプロモーション分岐メカニズムとともに使用していると主張する人もいますが、それはすべて素晴らしいものです。彼らは嘘をついている、自分をだます、またはあなたと同じ規模のシステムで働いていないかのいずれかです。
ブランチとマージは難しいです。特に、定期的に考えを変え、ロールバックなどを要求するビジネスの場合は特にそうです。
この文はあなたの命を救うかもしれません：SCMにあるものはビルドしたアーティファクトにあるものと同じではありません！
分岐に問題がある場合は、SCMを誤用していることが原因です。私たちは何年もそれをやっています。 SCMを使用して最終ビルドに何が入るかを決定するシステムが整っています。
それはSCMの仕事ではありません。 SCMは栄光のファイルサーバーです。 SCMのどのファイルをビルドに入れるかを決定するジョブは、ビルドツールに属します。
モジュールAは作業中で、毎週のリリースに入ります。モジュールBはモジュールAですが、プロジェクトXが含まれており、同じブランチで作業中ですが、リリースに組み込まれていません。将来のある時点で、プロジェクトXをリリースする必要があります。そのため、モジュールAの配置を停止し、モジュールBの配置を開始するようにビルドツールに指示します。
これについては、多くの泣き声やしわ寄せが見られます。どのような、そして一般的な遠吠え。これは、どんなに巧妙であっても、ファイルリポジトリのような単純なものを取り巻く感情のレベルです。
しかし、あなたの答えがあります。
絶対にブランチを使用する必要があります。これには多くの強みがあります。
- HDの故障やラップトップの紛失などにより作業が失われることを心配していて、メインCIが壊れない場合は、作業中に作業をチェックインできます。
- 自分のローカルCIをセットアップしてブランチを監視するだけで、CIを実行できます。
- 機能が突然保留になった場合（それが起こることは決してありません）、それを保留することができます。
難しいことは言い訳にはなりません。それを正しく行うには常により多くの努力が必要です。
2つのチームが独自のブランチで作業する場合、たとえmasterブランチを統合しても、他のチームの変更は表示されません。つまり、開発ブランチがバラバラになり、チームの1つがmasterとマージする場合、他のチームは多くの変更をリベースする必要があります。
そのため、機能のブランチがある場合でも、マスターブランチへのすべてのリファクタリングの「バックポート」を作成し、新しい機能のためにのみブランチを保持することをお勧めします。
- バックポートリファクタリング
場合によっては、機能スイッチを使用してまだテストされていない新しい機能を無効にする方が簡単かもしれません。そうすれば、他のすべてのチームに変更が表示され、ビッグバンのマージが発生する必要はありません。
- 機能スイッチを使用する
ブランチの主な問題は、開発が完了したときにメインブランチにマージするのが難しいことです。マージは手動でエラーが発生しやすいプロセスになる可能性があるため、ほとんどの場合は回避する必要があります。
分岐を好むいくつかの注目すべき例外は、大規模なリファクタリング、スプリントよりも開発に時間がかかる巨大な機能、またはそのスプリントの大部分で他の機能の開発を妨げる破壊的な機能です。
この種のブランチスキームをお勧めします。
リリース-テスト-開発
次に、開発から、開発者別および/または機能別に分岐します。
開発者はそれぞれ、ブランチを使用して、そこからマージし、そして開発ブランチに定期的に-理想的には毎日（それがコンパイルされることを条件として）分岐します。
この種のスキームは、同じコードベースの多くの開発者や複数のプロジェクトで非常にうまく機能します。
私の組織のプロセスでは、ブランチand（少し似ているプロセス）を継続的に統合しています。
大まかに見ると、開発者はメインラインとのマージについてあまり心配せず、ブランチにコミットするだけです。 （半）自動化プロセスは、メインラインに入る予定の機能をチェックし、それらのブランチをマージして製品をビルドします。このプロセスが機能するのは、実際に課題追跡からマージするこのプロセスを統合し、ビルドツールがマージするブランチを認識できるようにするためです。
doブランチを使用しますが、機能の詳細レベルでは使用しません。スプリントごとにブランチを使用します。本質的に分岐はIMOの悪いことではありません。これは、フィーチャーまたはスプリントレイヤーで[〜＃〜] soc [〜＃〜]の概念をシミュレートするためです。どのブランチがどの機能またはスプリントに属しているかを簡単に認識して管理できます。
私見の場合、答えは[〜＃〜] yes [〜＃〜]です。ブランチを使用する必要があります。