CVSの機能ブランチ？

Question

私はこの特定のプロジェクトでCVSを使用するというポリシーに拘束されているため、Gitのような他の何かに本当に切り替えたいのですが、できません。

したがって、私の本当の質問は次のようになります。リリースを行うたびにCVSに新しいブランチを作成するという慣習があります（タグ付けもしますが、それはポイント以外です）。これらをバージョンブランチと呼び、特定のバージョンを簡単にチェックアウトし、ホットフィックスを変更できるようにします。これがマイナーリリースです。

しかし、今では大規模でリスクに満ちた変更がいくつかあります。Gitで作業している場合、瞬く間に機能ブランチを作成することになります。しかし、CVSで作業しているときに、別のプロジェクトで機能ブランチを作成してみたところ、すぐに面倒なことがわかりました。たくさんのブランチができてしまい、どのブランチが同期され、どのブランチがマージされ、どのブランチが使用されなくなったかを追跡できなくなりました。

では、疑問符にもっと近づいて、CVSで機能ブランチを使用することは可能ですか？彼らはそれだけの価値があるにはあまりに面倒なのでしょうか、それとも最終的にそれらを使用しないことを残念に思うでしょうか？弾丸を噛んでHEADでコーディングを開始する必要がありますが、コーディングプロセスを可能な限り目立たない方法で導入するように曲げるべきですか？

Answer 1

機能ブランチで開発しているのがあなただけなら、Gitを「サンドボックス開発」として単純に使用できます。システムを変更し、変更が完了したら、それらをCVSリポジトリにマージします。

引き続き、中間作業成果物のソース管理のメリットを享受できます。

Answer 2

ストリーム化された行と呼ばれる分岐戦略の優れた議論があります。 -機能ブランチを使用する利点と欠点について説明します。

また、実装したいコード行の所有権とポリシーのオプションもカバーしています

Answer 3

考慮すべきことの1つは、メイントランクにマージしてから、機能ブランチを実際に閉じるすることです。このコンテキストでは、クローズとは単に実際の削除ではなく、ブランチを放棄することを意味します。

作業がマージされると、「存在する」ブランチは本当に必要ありません。

どのブランチが機能ブランチであるかを迅速に識別するために、命名規則に「FEAT_MY_FEATURE」というリークがあることをお勧めします。または「FEAT_20080926」 （開始日？）。これにより、リポジトリ構造を参照するときにこれらの機能ブランチをすべて簡単に無視できます。

Answer 4

私はこれが一般的な慣行であり、本当に痛かった環境で数年間働いてきました。マージは多くの時間を消費し、遅延の原因になるため、プロジェクト計画の一部であることを確認してください。

ブランチの文書化と特定の責任の割り当ては少し役立ちました。

2つのブランチが分岐するとCVSがうまく動作しないため、変更を増分的にマージするツールを作成する必要がありました（ブランチの先端をマージするのではなく、一度に1つの変更）。

頻繁に同期します（少なくとも1週間に1回）。

振り返ってみると、これにアプローチする最善の方法は、発散を最小限に抑え、たとえばスクラムを使用してリスクの高い開発をさまざまなマイルストーンに分割することです。

SCMパターンを読むこともお勧めします。この本には多くの良いアドバイスが含まれています。