開発コードと製品コードをどのように維持しますか？[閉まっている]

コードを維持する際に従うべきベストプラクティスと経験則は何ですか？開発ブランチに本番環境対応のコードのみを含めることは良い習慣ですか、それともテストされていない最新のコードを開発ブランチで利用できるようにする必要がありますか？

開発コードと製品コードをどのように維持していますか？

編集-補足質問-開発チームは「commit-as-soon-as-possible-and-often-even-if-if-the-code-contains-minor-bugs-or-is-incomplete」プロトコルまたは「commit- DEVELOPMENTブランチにコードをコミットする際の「完全なコードのみ」のプロトコル？

アップデート2019：

最近の質問は、Gitを使用するコンテキストで見られ、分散開発ワークフロー（主にGitHubを介して共同作業）を使用して10年間が一般的なベストプラクティスを示しています。

• masterはいつでも本番環境にデプロイできる状態のブランチです。次のリリースでは、選択した機能ブランチのセットがにマージされていmasterます。
• dev（または統合ブランチ、または ' next'）は、次のリリース用に選択された機能ブランチが一緒にテストされるブランチです
• maintenance（またはhot-fix）ブランチは、現在のリリースの進化/バグ修正のための1つである可能性がマージにバックアップをdevし、またはmaster

ワークフローのようなもの（あなたがマージされませんdevにmaster、しかし、あなたがにのみ機能ブランチをマージところdev、その後に、選択された場合masterのGitで実装されているためには、次のリリースのための準備ができていない枝を備えています簡単に落とすことができるようにします）gitworkflowを使用したリポジトリ自体（1つの単語、ここで説明）
詳しくは、をご覧くださいrocketraman/gitworkflow。これとトランクベースの開発の歴史は、Adam Dymitrukによるこの記事のコメントと議論に記載されています。

^{（ソース：Gitworkflow：タスク指向のプライマー）}

注：その分散ワークフローでは、いつでもコミットして個人ブランチにWIP（Work In Progress）を問題なくプッシュできます。コミットを機能ブランチの一部にする前に、コミットを再編成（git rebase）できます。

元の回答（2008年10月、10年以上前）

それはすべて、リリース管理の逐次的な性質に依存します

まず、トランクのすべてが本当に次のリリースのためのものですか？現在開発されている機能の一部は次のとおりです。

• あまりにも複雑で、まだ洗練する必要があります
• 間に合わない
• 興味深いが、この次のリリースではない

この場合、トランクには現在の開発作業が含まれている必要がありますが、次のリリースの前に定義されたリリースブランチは、適切なコード（次のリリースで検証済み）のみがマージされ、ホモロゲーションフェーズ中に修正される統合ブランチとして機能します。そして、生産に入ると最終的に冷凍されます。

本番コードに関しては、次の点に留意しながら、パッチブランチを管理する必要もあります。

• 最初のパッチセットは、実際に最初の本番リリースの前に始まる場合があります（時間内に修正できないいくつかのバグで本番環境に入ることがわかっていますが、別のブランチでそれらのバグの作業を開始できます）
• 他のパッチブランチには、明確に定義されたプロダクションラベルから開始する贅沢があります。

devブランチに関しては、次のように並行して行う必要のある他の開発作業がない限り、1つのトランクを使用できます。

• 大規模なリファクタリング
• 他のクラスでの呼び出し方法を変更する可能性がある新しいテクニカルライブラリのテスト
• 重要なアーキテクチャの変更を組み込む必要がある新しいリリースサイクルの開始。

ここで、開発とリリースのサイクルが非常に順次的である場合、他の回答が示唆するように、1つのトランクと複数のリリースブランチに進むことができます。これは、すべての開発が次のリリースに進むことが確実で、パッチを適用できるリリースブランチの開始点として機能する小規模なプロジェクトで機能します。これは名目上のプロセスですが、より複雑なプロジェクトが発生するとすぐに...それだけでは不十分です。

Ville M.のコメントに答えるには：

• 開発ブランチは「開発者ごとに1つのブランチ」を意味するわけではないことに注意してください（各開発者が他の作業をマージして作業を表示/取得する必要があるため、「マージマッドネス」がトリガーされます）が、開発ごとに1つの開発ブランチ努力。
• これらの努力はトランクにマージバック（または定義、他の「メイン」またはリリースブランチ）する必要がある場合、これは開発者の仕事ではない I繰り返し、NOT - - SCマネージャー（解決する方法を知っているだろう競合するマージ）。プロジェクトリーダーがマージを監督する場合があります。つまり、時間どおりに開始/終了するようにします。
• 実際にマージを実行するために選択した人に関係なく、最も重要なのは次のとおりです。
  • マージの結果をデプロイ/テストできるユニットテストやアセンブリ環境を用意する。
  • マージが複雑すぎて解決できない場合は以前の状態に戻ることができるように、マージの開始前にタグを定義しておく必要があります。

を使用しております：

• 開発ブランチのみ

プロジェクトが完成に近づくまで、またはマイルストーンバージョン（製品デモ、プレゼンテーションバージョンなど）を作成するまで、現在の開発ブランチから（定期的に）次のものに分岐します。

• リリースブランチ

リリースブランチに追加される新機能はありません。重要なバグのみがリリースブランチで修正され、これらのバグを修正するコードは開発ブランチに再統合されます。

開発と安定した（リリース）ブランチの2つの部分からなるプロセスにより、私たちの生活ははるかに楽になります。ブランチをさらに導入することで、その一部を改善できるとは思いません。各ブランチには独自のビルドプロセスもあります。つまり、数分ごとに新しいビルドプロセスが生成されるため、コードチェックイン後、すべてのビルドバージョンとブランチの新しい実行可能ファイルが約30分で作成されます。

たまに、1人の開発者が新しい未検証の技術に取り組んだり、概念実証を作成したりするためのブランチもあります。しかし一般的には、変更がコードベースの多くの部分に影響を与える場合にのみ行われます。これは平均して3〜4か月ごとに発生し、そのようなブランチは通常1〜2か月以内に再統合（または廃棄）されます。

あなたは「スキップして統合の地獄に直接移動する」ので、一般的に私はすべての開発者が自分のブランチで作業するという考えは好きではありません。私はそれに対して強く助言します。共通のコードベースがある場合は、すべて一緒に作業する必要があります。これにより、開発者はチェックインについてより警戒し、経験を積むとすべてのコーダーがどの変更がビルドを壊す可能性があるかを知っているため、そのような場合のテストはより厳密になります。

チェックインの早い質問について：

PERFECT CODEのみをチェックインする必要がある場合は、実際には何もチェックインされません。コードは完璧ではありません。QAがコードを検証およびテストするには、新しい実行可能ファイルを構築できるように、コードを開発ブランチに配置する必要があります。

私たちにとっては、機能が完成して開発者によってテストされると、チェックインされます。既知の（致命的でない）バグがある場合はチェックインされることもありますが、その場合、バグの影響を受ける人は通常通知されます。不完全で進行中のコードもチェックインできますが、それがクラッシュや既存の機能の破壊などの明らかな悪影響を引き起こさない場合に限ります。

時折避けられないコードとデータの組み合わせチェックインにより、新しいコードがビルドされるまでプログラムが使用できなくなります。最低でも、チェックインコメントに「WAIT FOR BUILD」を追加するか、電子メールを送信します。

価値のあるものについては、これが私たちのやり方です。

ほとんどの開発はトランクで実行されますが、実験的な機能やシステムを破壊する可能性があるものは、独自のブランチを取得する傾向があります。これは、すべての開発者が常に作業コピーにすべての最新バージョンを持っていることを意味するため、かなりうまくいきます。

それは完全にそれを壊すことが完全に可能であるので、トランクを漠然と機能する順序に保つことが重要であることを意味します。実際にはそれほど頻繁に発生することはなく、めったに重大な問題になることはありません。

本番リリースでは、トランクのブランチを作成し、新機能の追加を停止し、リリースの準備ができるまで、バグの修正とブランチのテスト（通常はトランクにマージして戻す）を行います。その時点で、トランクに最終的にマージして、すべてがそこにあることを確認してからリリースします。

その後、必要に応じてリリースブランチでメンテナンスを実行できます。これらの修正はトランクに簡単にマージできます。

私はこれが完璧なシステムであるとは主張していません（まだいくつかの穴があります-私たちのリリース管理はまだ十分に厳格なプロセスではないと思います）が、それは十分に機能します。

なぜ誰もまだこれについて言及しないのですか？成功したGit分岐モデル。

私にとっては究極の分岐モデルです！

プロジェクトが小さい場合は、常にすべての異なるブランチを使用しないでください（おそらく、小さな機能の機能ブランチをスキップできます）。しかし、そうでなければ、それはそれを行う方法です！

ブランチの開発コード、トランクにタグ付けされたライブコード。

「完全なコードのみをコミットする」ルールがある必要はありません。開発者が見逃したものは、コードレビュー、ブランチテスト、回帰テスト、最終QAテストの4か所で取得する必要があります。

詳細な手順は次のとおりです。

1. ブランチですべての開発を行い、定期的にコミットします。
2. すべての開発が完了したら、変更の独立したコードレビュー。
3. 次に、ブランチをTestingに渡します。
4. ブランチテストが完了したら、コードをリリース候補ブランチにマージします。
5. リリース候補ブランチは、個々のマージ後に回帰テストされます。
6. すべての開発ブランチがマージされた後にRCで実行された最終的なQAおよびUAテスト。
7. QAとUATが渡されたら、リリースブランチをMAIN / TRUNKブランチにマージします。
8. 最後に、その時点でトランクにタグを付け、そのタグをLiveにデプロイします。

開発者はトランク（svnスタイル）に入り、リリース（製品コード）は独自のブランチを取得します

これは「分岐目的モデル」です（分岐モデルの重要性 /！\ pdfの図3 ）。

この問題は、製品コード（メイントランク）と開発コード（開発者ごとに独自のブランチがある）を完全に分離することで解決します。

（QAとコードレビュー担当者によって）完全にチェックされるまで、コードを本番コードに組み込むことはできません。

これにより、どのコードが機能するかについて混乱が生じることはなく、常にメインブランチになります。

ああそうです-他に1つあります-非生産コード（つまり、決してリリースされないコード-ツールスクリプト、テストユーティリティなど）をcvs HEADに保持します。通常は明確にマークする必要があるため、「誤って」リリースすることはありません。

トランクで開発し、2週間ごとに分岐して生産を開始します。ブランチでは重大なバグのみが修正され、残りはさらに2週間待つことができます。

トランクの唯一のルールは、コミットによって何も壊されないようにすることです。wipコードとテストされていないコードを管理するには、適切なifステートメントを追加して、オンとオフを簡単に切り替えられるようにします。

基本的に、いつでもトランクを分岐して本番環境に置くことが可能です。

私はgitを使用していて、masterとmaintの 2つのブランチがあります。

• マスター-開発コード
• maint-生産コード

コードを製品版にリリースするときに、タグを付けて、masterをmaintブランチにマージします。私は常にmaintブランチからデプロイします。開発ブランチからのパッチパッチをmaintブランチにチェリーピックしてパッチを展開します。

現在本番環境にあるもの、またはまもなく展開されるものを含む「リリース」ブランチがあります（すでにほとんどのQAに合格しています）

各プロジェクト、または場合によっては他のユニットには、リリースから分岐した独自の分岐があります。

変更は、プロジェクトの開発者によって、プロジェクトの独自のブランチにコミットされます。定期的に、リリースは開発ブランチにマージされます。

ブランチの作業パッケージがすべてQAされたら（単体テスト、システムテスト、コードレビュー、QAレビューなど）、ブランチはリリースブランチにマージされます。新しいビルドはリリースブランチからビルドされ、最終検証はそのバージョンで行われます。

マージが行われた後に問題が発見されるまで、プロセスは基本的に問題ありません。WPがマージされた後に「スタック」した場合、修正されるまでWPはすべてを保持します（スタックされたものが解放されるまで、次のリリースを行うことはできません）。

また、多少柔軟性があります。非常に短い変更（1〜2日など）でリリースされた場合、リリースブランチで非常に些細な変更が直接発生する可能性があります。

なんらかの理由で変更が直接本番環境に適用された場合（顧客に影響する重大な問題であり、修正するためにコードをただちに変更する必要があった）、それらの変更はBRANCH_RELEASEに戻​​されます。それはほとんど起こりません。

プロジェクトによって異なります。Webコードはほぼ一貫してチェックインされますが、アプリケーションコードはコンパイルされる場合にのみチェックインされます。これは、私たちがリリースする方法とかなり似ていることに気づきました。アプリケーションが厳しい期限に達している間は、いつでもWebスタッフが増えます。どちらの方法でも品質の低下は見られません。