私は政府機関によって規制されている会社で働いています。彼らは毎年特定の仕様を指定し、多くの場合、コードベースの多くを変更する必要がある変更を行います。
そうは言っても、土壇場での実装のストレスや急ぎを避けるために、事前に変更を加えたいと思います。
コードを他のすべての関連コードと一緒にバケットに保存して、期限を待っている間に機能やバグの修正を行うことができるようにするための最良の方法は何ですか？
メインリポジトリからプライベートブランチを作成することはできますか？–carlosfigueira _
わからない。それはチームの努力ですが、プライベートは彼らも働くことを可能にしますか？私たちは皆、個別のプライベートブランチを作成しますか、それとも1つの大きなブランチを作成しますか？私の最大の関心事は、これらすべての変更を最新のバグ修正と機能とマージしようとすることです。悪夢のようです。プライベートブランチがこれを助けるなら、私はそれらを調べます。
別の（これを機能と呼びます）ブランチを作成する必要があります。変更を加え、Mainからこの機能ブランチに継続的にマージして、Mainにマージする準備ができたときに大きなマージの問題が発生しないようにします。変更をマージして実装する準備ができたら、機能ブランチからメインにマージし、最終的にリリースブランチにマージします。
これは、構成管理のルーブリックに該当します。BradAppletonの著書「 SoftwareConfigurationManagementPatters：Effective Teamwork、PracticalIntegration 」を読む必要があります。私は必ずしもすべてに同意するわけではありませんが、彼にはいくつかの良いアドバイスがあります。
CMのその他の優れたリソースは、CM Crossroadsであり、USENETニュースグループcomp.software.config-mgtでもあります。
物事を行うにはいくつかの方法があります。
リリース（またはリリース候補）時にトランクとブランチで開発します。
このアプローチには、進行中の開発がすでにトランクにあるという利点があります。実行する必要がある唯一のマージは、バグ修正をリリースからトランクおよび他のリリースに伝播することです。
リリースごとのブランチ。ブランチで開発し、リリース時にトランクにマージします。
このアプローチでは、リリースの作業を開始するときに、トランクから新しいブランチが切り取られます。作業が「リリース対応」の場合、トランクにマージされて戻されるため、トランクはリリースのタイムラインを表します。ここでの利点は、トランクとその履歴がかなりきれいに保たれることです。誤ったスタートなどはすべてブランチに保持されます。特に複数のリリースが同時に機能している場合の欠点は、トランク内で2つのリリースが互いにステップする場合、トランクへのマージが困難になる可能性があることです。これは、競合状態です。
機能ごとのブランチ。機能を組み立ててリリースを作成します。
これは上記と似ていますが、よりきめ細かくなります。同じ種類の長所/短所が適用されます。
あなたがやりたいと思うことのために、私はあなたの既存の「リリースされた」コードラインから新しいブランチを作成します。新しいコードラインで保留中の変更を行います。プッシュするときは、メインのコードラインにマージします。基本的には、新機能のブランチです。
もう1つのアプローチは、現在のコードベースに「ダーク」な新機能を実装し、必要に応じてそれらを有効にできる構成スイッチを使用することです。これにより、分岐が回避され、機能を簡単にオンにできます。「ダーク」モードでもシステムが変更前と同じように機能することを確認するためにすべてを回帰テストする必要があるため、これには追加のQA作業が必要です。また、当然、新しい変更をテストして、正しく機能することを確認する必要があります。