開発コードと製品コードをどのように管理しますか？
コードを維持しながら従うべきベストプラクティスと経験則は何ですか？開発ブランチで本番対応のコードのみを使用することをお勧めしますか、それともテストされていない最新のコードを開発ブランチで使用できるようにする必要がありますか？
開発コードと製品コードをどのように管理していますか？
編集-補足の質問-開発チームは、「できるだけ早く、できるだけ頻繁に、コードに含まれるマイナーバグ、または不完全」プロトコルまたは「コミット- DEVELOPMENTブランチにコードをコミットする際の「完全なコードのみ」のプロトコル
更新2019：
最近では、質問はGitを使用したコンテキストで見られ、10年間の使用 分散 開発 ワークフロー （主に GitHubを介して ）一般的なベストプラクティスを示します。
masterは、本番環境にいつでも展開できるブランチです。次のリリースでは、選択された機能ブランチのセットがmasterにマージされます。dev（または統合ブランチ、または 'next'）は、次のリリース用に選択された機能ブランチが一緒にテストされるものですmaintenance（またはhot-fix）ブランチは、現在のリリースの進化/バグ修正のためのブランチです。devおよびmasterへのマージの可能性がある
そのようなワークフロー（devにmasterをマージせず、フィーチャーブランチのみをdevにマージし、選択した場合はmasterに順番にマージするワークフロー次のリリースの準備ができていない機能ブランチを簡単にドロップできるようにする）は、gitworkflow（1ワード、 ここに示す ）。
詳細は rocketraman/gitworkflow をご覧ください。
（ソース： Gitworkflow：A Task-Oriented Primer ）
注：その分散ワークフローでは、いつでもいつでもコミットでき、問題なく個人用ブランチにいくつかのWIP（進行中の作業）をプッシュできます：コミットを機能ブランチの一部にする前にコミットを再編成（git rebase）できます。
元の回答（2008年10月、10年以上前）
すべてはに依存しますリリース管理のシーケンシャルな性質
まず、トランク内のすべてが本当に次のリリースのために？現在開発されている機能の一部は次のとおりです。
- 複雑すぎて、まだ洗練する必要がある
- 間に合わない
- 興味深いが、この次のリリースではない
この場合、trunkには現在の開発努力が含まれている必要がありますが、次のリリースの前に早期に定義されたリリースブランチはconsolidation branchとして機能し、適切なコードのみ（次のリリースで検証済み）はマージされ、その後、認証段階で修正され、最終的に本番稼働中にフリーズされます。
本番コードに関しては、パッチブランチも管理する必要がありますが、次の点に注意してください。
- パッチの最初のセットは、実際に本番環境に最初にリリースする前に実際に開始される場合があります（時間内に修正できないバグがある場合は本番環境に入りますが、別のブランチでそれらのバグの作業を開始できます）
- 他のパッチブランチは、明確に定義されたプロダクションラベルから始めることができます。
Devブランチに関しては、他の開発努力が必要な場合を除き、1つのトランクを使用できますin parallelのように：
- 大規模なリファクタリング
- 他のクラスで物事を呼び出す方法を変更する可能性のある新しいテクニカルライブラリのテスト
- 重要なアーキテクチャの変更を組み込む必要がある新しいリリースサイクルの開始。
これで、開発とリリースのサイクルが非常に連続的である場合、他の回答が示唆するように、1つのトランクと複数のリリースブランチに進むことができます。これは、すべての開発が次のリリースに確実に移行する小規模なプロジェクトで機能し、フリーズするだけで、パッチを適用できるリリースブランチの開始点として機能します。それは名目上のプロセスですが、より複雑なプロジェクトができたらすぐに...もう十分ではありません。
Ville M.のコメントに答えるには：
- devブランチは「開発者ごとに1つのブランチ」（各開発者が作業を表示/取得するために他の作業をマージする必要があるため、「マージの狂気」を引き起こす）を意味しないことに注意してください努力。
- これらの作業をトランク（または他の「メイン」またはユーザーが定義したリリースブランチ）にマージする必要がある場合、これは開発者の作業です。not-繰り返さない、SC Manager（競合するマージの解決方法がわからない）。プロジェクトリーダーはマージを監督することができます。つまり、スケジュールどおりに開始/終了するようにします。
- 実際にマージを行うために選択する人は誰でも、最も重要なのは：
- マージの結果を展開/テストできる単体テストやアセンブリ環境を用意します。
- タグを定義したbeforeマージの開始が以前の状態に戻ることができるようにする解決します。
を使用しております：
- 開発ブランチのみ
プロジェクトが完了に近づくまで、またはマイルストーンバージョン（製品デモ、プレゼンテーションバージョンなど）を作成するまで、（通常）現在の開発ブランチから次のブランチに分岐します。
- リリースブランチ
リリースブランチには新しい機能はありません。リリースブランチでは重要なバグのみが修正され、これらのバグを修正するコードは開発ブランチに再統合されます。
開発と安定した（リリース）ブランチの2つの部分からなるプロセスにより、私たちの生活はずっと楽になり、ブランチを追加することでその部分を改善できるとは思いません。各ブランチには独自のビルドプロセスもあります。つまり、数分ごとに新しいビルドプロセスが生成されるため、コードチェックイン後、約30分以内にすべてのビルドバージョンとブランチの新しい実行可能ファイルが作成されます。
たまに、1人の開発者が新しい未検証の技術に取り組んだり、概念実証を作成したりするためのブランチもあります。しかし、一般的には、変更がコードベースの多くの部分に影響する場合にのみ行われます。これは平均して3〜4か月ごとに発生し、そのようなブランチは通常1〜2か月以内に再統合（または廃棄）されます。
一般的に私はすべての開発者が自分のブランチで作業しているという考えが好きではありません。なぜなら、あなたは「統合地獄に直行して移動する」からです。私はそれに対して強く助言します。共通のコードベースがある場合は、すべて一緒に作業する必要があります。これにより、開発者はチェックインについてより慎重になり、経験により、すべてのコーダーはどの変更がビルドを壊す可能性があるかを知っているため、そのような場合のテストはより厳密になります。
チェックインの初期の質問：
PERFECT CODEのみをチェックインする必要がある場合、実際には何もチェックインしないでください。完璧なコードはありません。QAが検証およびテストするには、開発ブランチにある必要があります。新しい実行可能ファイルを作成できます。
つまり、機能が完成して開発者によってテストされると、チェックインされます。既知の（致命的でない）バグがある場合でもチェックインされる場合がありますが、その場合、バグの影響を受ける人は通常通知されます。不完全で進行中のコードもチェックインできますが、クラッシュや既存の機能の破壊など、明らかな悪影響が発生しない場合に限ります。
避けられないコードとデータのチェックインを組み合わせることにより、新しいコードがビルドされるまでプログラムを使用できなくなります。少なくとも、チェックインコメントに「ビルドの待機」を追加したり、電子メールを送信したりすることです。
価値のあることは、これが私たちのやり方です。
ほとんどの開発はトランクで実行されますが、システムを破壊する可能性のある実験的な機能または事柄は、独自のブランチを取得する傾向があります。これは、すべての開発者が常に作業コピー内のすべての最新バージョンを持っていることを意味するため、非常にうまく機能します。
トランクを完全に破損させることは完全に可能であるため、トランクを曖昧に機能する状態に保つことが重要であることを意味します。実際には、それは頻繁に起こることではなく、めったに重大な問題ではありません。
本番リリースでは、トランクをブランチし、新機能の追加を停止し、リリースの準備ができるまでブランチのバグ修正とテスト（通常はトランクにマージ）に取り組みます。その時点で、トランクへの最終マージを行い、すべてがそこにあることを確認してからリリースします。
その後、必要に応じてリリースブランチでメンテナンスを実行でき、それらの修正をトランクに簡単にマージできます。
私はこれが完璧なシステムであると主張していません（そして、まだいくつかの穴があります-リリース管理はまだ十分にタイトなプロセスではないと思います）が、それは十分に機能します。
まだ誰もこれに言及していないのはなぜですか？ 成功したGit分岐モデル 。
それは私にとって究極の分岐モデルです！
プロジェクトが小さい場合は、常にすべての異なるブランチを使用しないでください（おそらく、小さな機能については機能ブランチをスキップできます）。しかし、そうでなければ、それはそれを行う方法です！
ブランチの開発コード、Trunkでタグ付けされたライブコード。
「完全なコードのみをコミットする」ルールは必要ありません。開発者が見落としたものは、コードレビュー、ブランチテスト、リグレッションテスト、最終QAテストの4か所で取得する必要があります。
詳細なステップバイステップの説明は次のとおりです。
- ブランチですべての開発を行い、進行中に定期的にコミットします。
- すべての開発が完了したら、変更の独立したコードレビュー。
- 次に、ブランチをテストに渡します。
- ブランチのテストが完了したら、リリース候補ブランチにコードをマージします。
- Release Candidateブランチは、個々のマージ後に回帰テストされます。
- すべての開発ブランチがマージされた後、RCで実行される最終QAおよびUAテスト。
- QAとUATが渡されたら、リリースブランチをMAIN/TRUNKブランチにマージします。
- 最後に、その時点でトランクにタグを付け、そのタグをLiveに展開します。
devはトランク（svnスタイル）に入り、リリース（プロダクションコード）は独自のブランチを取得します
それは「分岐目的モデル」です（ 分岐モデルの重要性 /！\ pdfの図3）
本番コード（メイントランク）を開発コード（すべての開発者が独自のブランチを持っている）から完全に分離することにより、この問題を解決します。
（QAおよびコードレビューアによって）完全にチェックされるまで、実稼働コードにコードを含めることはできません。
このように、どのコードが機能するかについて混乱はなく、常にメインブランチです。
トランクで開発し、その後2週間ごとに分岐し、実稼働します。ブランチでは重大なバグのみが修正され、残りはさらに2週間待つことができます。
トランクの唯一のルールは、コミットが何も壊さないことです。 wipコードとテストされていないコードを管理するには、適切なif文を追加して、オンとオフを簡単に切り替えられるようにします。
基本的には、いつでもトランクを分岐して本番環境に入れることができます。
そうそう-もう1つ-私たちはcvs HEADに非生産コード（つまり、決してリリースされないもの-ツールスクリプト、テストユーティリティなど）を保持しています。通常、誰も「偶然」リリースしないように、明確にマークする必要があります。
プロジェクトに依存します。 Webコードはかなり一貫してチェックインされますが、アプリケーションコードはコンパイルされた場合にのみチェックインされます。これは私たちが物事をリリースする方法にかなり似ていることに気づきました。アプリケーションが厳しい締め切りに達する間、Webスタッフはできる限りアップします。ただし、どちらの方法でも品質の低下は見られません。
Gitを使用し、2つのブランチがあります：masterおよびmaint
- マスター-開発コード
- maint-製品コード
コードを実稼働環境にリリースするとき、タグを付けてmasterとmaintブランチをマージします。常にmaintブランチからデプロイします。開発ブランチからのパッチ私はそれらをmaintブランチにチェリーピックし、パッチを展開します。
現在リリースされているか、まもなく展開されるものを含む「リリース」ブランチがあります（すでにほとんどのQAに合格しています）
各プロジェクト、または場合によっては他のユニットには、リリースから分岐する独自のブランチがあります。
変更は、プロジェクトの開発者によってプロジェクトのブランチにコミットされます。リリースは定期的に開発ブランチにマージされます。
ブランチ上の作業パッケージがすべてQAになったら（ユニットテスト、システムテスト、コードレビュー、QAレビューなど）、ブランチはリリースブランチにマージされます。新しいビルドはリリースブランチからビルドされ、そのバージョンで最終検証が行われます。
マージが完了して問題が発見されるまで、プロセスは基本的に問題ありません。 WPがマージされた後に「スタック」した場合、それが修正されるまでその後すべてを保持します（スタックしているリリースがリリースされるまで、別のリリースはできません）。
また、多少柔軟性があります。非常に短い時間スケール（1〜2日程度）でリリースされている場合、リリースブランチで非常に些細な変更が直接発生する可能性があります。
何らかの理由で変更が本番に直接適用された場合（お客様が影響を受ける重要な本番の問題で、修正するには直ちにコードを変更する必要があります）、それらの変更はBRANCH_RELEASEに戻されます。それはほとんど起こりません。