5

この特定のプロジェクトでは CVS を使用することがポリシーによって義務付けられているため、実際には Git などの別のものに切り替えたいのですが、できません。

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

しかし今、私はいくつかの大規模でリスクの高い変更を予定しており、Git で作業していたら、瞬く間に機能ブランチを作成していたでしょう。しかし、CVS で作業していて、別のプロジェクトでフィーチャー ブランチを作成しようとしたところ、すぐに面倒なことがわかりました。多くのブランチができてしまい、同期されたブランチ、マージが必要なブランチ、使用されなくなったブランチを見失いました。

それでは、クエスチョン マークに少しずつ近づくと、CVS でフィーチャー ブランチを使用することは実現可能でしょうか? それらは面倒すぎて価値がありませんか、それとも最終的にそれらを使用しないことを残念に思うことになりますか? 弾丸をかじってHEADでコーディングを開始し、コーディングプロセスを曲げて、可能な限り目立たない方法で変更を導入する必要がありますか?

4

4 に答える 4

5

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

中間作業成果物のソース管理の利点は引き続き得られます。

于 2008-09-26T10:50:53.123 に答える
3

役立つかもしれないストリームラインと呼ばれる分岐戦略に関する優れた議論があります - それは機能分岐を使用することの長所と短所を説明しています.

また、実装したいコード行の所有権とポリシーのオプションについても説明します。

于 2008-09-26T12:39:47.610 に答える
1

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

ブランチを文書化し、それらに特定の責任を割り当てることは、少し役に立ちました。

2 つの分岐が分岐すると CVS は適切に動作しないため、変更を段階的に (分岐の先端を結合するのではなく、一度に 1 つの変更を) 結合するのに役立つツールを作成する必要がありました。

頻繁に同期します (少なくとも週に 1 回)。

振り返ってみると、これに取り組む最善の方法は、たとえばスクラムを使用して、相違を最小限に抑え、リスクの高い開発をさまざまなマイルストーンに分割することだと思います。

SCM Patternsも読むことをお勧めします。この本にはたくさんの良いアドバイスが含まれています。

于 2008-09-26T13:47:50.630 に答える
1

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

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

どのブランチがフィーチャー ブランチであるかをすばやく特定するために、「FEAT_MY_FEATURE」または「FEAT_20080926」(開始日?) という命名規則をリークすることをお勧めします。これにより、リポジトリ構造を参照するときに、これらすべてのフィーチャー ブランチを簡単に無視できます。

于 2008-09-26T10:47:39.403 に答える