コードを維持する際に従うべきベスト プラクティスと経験則は何ですか? 開発ブランチに本番用の準備が整ったコードのみを配置することは良い習慣ですか、それともテストされていない最新のコードを開発ブランチで利用できるようにする必要がありますか?
開発コードと本番コードをどのように維持していますか?
編集 - 補足質問 - あなたの開発チームは、「可能な限りすぐにコミットし、コードにマイナーなバグが含まれているか不完全である場合でも」プロトコルまたは「コミット-コードを DEVELOPMENT ブランチにコミットする際に、ONLY-perfect-code" プロトコルを実行しますか?
2019年の更新：
最近では、質問はGitを使用するコンテキストで見られ、その分散開発ワークフロー（主にGitHubを介したコラボレーション）を10年間使用すると、一般的なベストプラクティスが示されます。
masterは、いつでも本番環境にデプロイできるブランチです。次のリリースでは、選択した機能ブランチのセットがにマージされていmasterます。dev（または統合ブランチ、または' next'）は、次のリリース用に選択された機能ブランチが一緒にテストされるブランチです。maintenance（またはhot-fix）ブランチは、現在のリリースの進化/バグ修正用のブランチであり、およびまたはにマージされる可能性があります。devmasterこの種のワークフロー（にマージしないが、機能ブランチのみをにマージし、dev選択した場合は、次のリリースの準備ができていない機能ブランチを簡単に削除できるようにする）はGitに実装されていますgitworkflowを使用したrepo自体（1つの単語、ここに示されています）。
詳しくはをご覧ください。これを行ったvsトランクベースの開発の歴史は、AdamDymitrukによるこの記事のコメントとディスカッションに記載されています。masterdevmasterrocketraman/gitworkflow
注：その分散ワークフローでは、いつでもコミットして、問題なくWIP（Work In Progress）をパーソナルブランチにプッシュできます。コミットを機能ブランチの一部にする前に、コミットを再編成（git rebase）することができます。
元の回答（2008年10月、10年以上前）
それはすべて、リリース管理のシーケンシャルな性質に依存します
まず、トランク内のすべてが本当に次のリリースのためのものですか？現在開発されている関数のいくつかは次のとおりです。
この場合、トランクには現在の開発作業が含まれている必要がありますが、次のリリースの前に定義されたリリースブランチは、適切なコード（次のリリースで検証済み）のみがマージされ、ホモロゲーションフェーズで修正される統合ブランチとして機能できます。そして最後にそれが生産に入るときに凍結しました。
本番コードに関しては、次の点に注意しながら、パッチブランチも管理する必要があります。
開発ブランチに関しては、次のように並行して行う必要のある他の開発作業がない限り、1つのトランクを持つことができます。
これで、開発とリリースのサイクルが非常に連続している場合は、他の回答が示唆するように、1つのトランクと複数のリリースブランチに進むことができます。これは、すべての開発が確実に次のリリースに移行する小さなプロジェクトで機能し、パッチを適用できるリリースブランチの開始点として機能します。これは名目上のプロセスですが、より複雑なプロジェクトがあるとすぐに...もう十分ではありません。
Ville M.のコメントに答えるには：
を使用しております：
プロジェクトが完成に近づくまで、またはマイルストーン バージョン (製品デモ、プレゼンテーション バージョンなど) を作成するまで、(定期的に) 現在の開発ブランチから次のブランチに分岐します。
リリース ブランチに追加される新機能はありません。重要なバグのみがリリース ブランチで修正され、これらのバグを修正するコードは開発ブランチに再統合されます。
開発ブランチと安定 (リリース) ブランチの 2 部構成のプロセスは、私たちの生活をずっと楽にしてくれます。さらに多くのブランチを導入することで、その一部を改善できるとは思いません。各ブランチには独自のビルド プロセスもあります。つまり、数分ごとに新しいビルド プロセスが生成されるため、コード チェックイン後、約 30 分以内にすべてのビルド バージョンとブランチの新しい実行可能ファイルが作成されます。
場合によっては、証明されていない新しいテクノロジに取り組んでいる、または概念実証を作成している 1 人の開発者向けのブランチもあります。ただし、一般的には、変更がコードベースの多くの部分に影響する場合にのみ行われます。これは平均して 3 ～ 4 か月ごとに発生し、そのようなブランチは通常 1 ～ 2 か月以内に再統合 (または廃止) されます。
一般的に、すべての開発者が自分のブランチで作業するという考えは好きではありません。「スキップして統合地獄に直接移動する」からです。私はそれに反対することを強くお勧めします。共通のコードベースがある場合は、全員が一緒に作業する必要があります。これにより、開発者はチェックインについてより慎重になり、経験により、すべてのコーダーはどの変更がビルドを壊す可能性があるかを知っているため、そのような場合のテストはより厳密になります。
チェックインの初期の質問について:
PERFECT CODEのみをチェックインする必要がある場合は、実際には何もチェックインしないでください。完全なコードはありません。QA が検証およびテストするには、新しい実行可能ファイルをビルドできるように開発ブランチにある必要があります。
私たちにとっては、機能が完成し、開発者によってテストされると、それがチェックインされることを意味します。既知の (致命的ではない) バグがある場合でもチェックインされる可能性がありますが、その場合、バグの影響を受ける人々は普通に通報。不完全で作業中のコードもチェックインできますが、クラッシュや既存の機能の破損などの明らかな悪影響を引き起こさない場合に限ります。
時々、避けられないコードとデータのチェックインの組み合わせにより、新しいコードがビルドされるまでプログラムが使用できなくなります。少なくとも、チェックイン コメントに「WAIT FOR BUILD」を追加するか、電子メールを送信するだけです。
それが価値があるのは、これが私たちのやり方です。
ほとんどの開発はトランクで実行されますが、実験的な機能やシステムを壊す可能性のあるものは、独自のブランチを取得する傾向があります。これは、すべての開発者が常に作業コピーにすべての最新バージョンを持っていることを意味するため、非常にうまく機能します。
トランクを完全に壊すことが完全に可能であるため、トランクを漠然と機能する状態に保つことが重要であることを意味します。実際には、これは頻繁には発生せず、重大な問題になることはめったにありません。
本番リリースでは、トランクを分岐し、新機能の追加を停止し、リリースの準備ができるまで分岐のバグ修正とテスト（通常はトランクにマージして戻します）に取り組みます。その時点で、トランクへの最終マージを実行して、すべてがそこにあることを確認してから、リリースします。
その後、必要に応じてリリースブランチでメンテナンスを実行でき、それらの修正をトランクに簡単にマージして戻すことができます。
これが完璧なシステムであるとは言いませんが（まだいくつかの穴があります。リリース管理はまだ十分に厳密なプロセスではないと思います）、十分に機能します。
ブランチの開発コード、トランクにタグ付けされたライブ コード。
「完全なコードのみをコミットする」というルールは必要ありません。開発者が見逃したものはすべて、コード レビュー、分岐テスト、回帰テスト、最終 QA テストの 4 つの場所で取り上げるべきです。
より詳細なステップバイステップの説明は次のとおりです。
dev はトランク (svn スタイル) に入り、リリース (プロダクション コード) は独自のブランチを取得します。
それが「目的別分岐モデル」です (分岐モデルの重要性/!\ pdf の図 3)。
この問題を解決するには、製品コード (メイン トランク) を開発コード (すべての開発者が独自のブランチを持つ) から完全に分離します。
(QA およびコード レビュー担当者によって) 徹底的にチェックされる前に、コードを製品コードに組み込むことは許可されません。
この方法では、どのコードが機能するかについて混乱することはなく、常にメイン ブランチになります。
トランクで開発し、2 週間ごとに分岐して本番環境に投入します。ブランチでは重大なバグのみが修正され、残りはさらに 2 週間待つことができます。
トランクの唯一のルールは、コミットが何かを壊してはならないということです。wip コードとテストされていないコードを管理するには、適切な if ステートメントを追加して、オンとオフを簡単に切り替えられるようにします。
基本的にいつでもトランクを分岐して本番環境に入れることができるはずです。
そうそう - もう 1 つ - 非生産コード (つまり、決してリリースされないコード - ツール スクリプト、テスト ユーティリティなど) を cvs HEAD に保持します。通常、「誤って」リリースしないように、明確にマークする必要があります。
私は git を使用しており、masterとmaintの 2 つのブランチがあります。
コードを本番環境にリリースするときは、タグを付けてmasterをmaintブランチにマージします。私はいつもmaintブランチからデプロイしています。開発ブランチからのパッチ 私はそれらをチェリー ピックして maint ブランチに配置し、パッチをデプロイします。
現在運用中のもの、またはまもなく展開されるものを含む「リリース」ブランチがあります (すでにほとんどの QA に合格しています)。
各プロジェクト、または場合によっては他のユニットには、リリースから分岐した独自の分岐があります。
変更は、プロジェクトの開発者によって、プロジェクトの独自のブランチにコミットされます。定期的に、リリースは開発ブランチにマージされます。
ブランチの作業パッケージがすべて QA (単体テスト、システム テスト、コード レビュー、QA レビューなど) されると、ブランチはリリース ブランチにマージされます。新しいビルドはリリース ブランチからビルドされ、最終的な検証はそのバージョンで行われます。
マージが完了した後、問題が発見されるまで、プロセスは基本的に OK です。マージ後に WP が「動かなくなった」場合、それが修正されるまで、それ以降のすべてが保持されます (動かなくなった WP がリリースされるまで、別のリリースを行うことはできません)。
また、ある程度柔軟です。リリース ブランチが非常に短い時間スケール (1 ～ 2 日程度) でリリースされた場合、非常に些細な変更がリリース ブランチで直接発生する可能性があります。
なんらかの理由で変更が本番環境に直接適用された場合 (顧客に影響を与える重大な本番環境の問題であり、修正するためにコードをすぐに変更する必要がありました)、それらの変更は BRANCH_RELEASE に戻されます。それはめったに起こりません。
プロジェクトによって異なります。Web コードはほぼ一貫してチェックインされますが、アプリケーション コードはコンパイルされた場合にのみチェックインされます。これは、私たちが物をリリースする方法とかなり似ていることに気付きました。アプリケーションが厳しい締め切りに達している間は、可能な限り Web の情報がアップされます。ただし、どちらの方法でも品質の低下は見られません。