Subversionでブランチを管理する

Question

私は何か正しいことをしているとは思わない。私は私たちの組織のウェブサイトの私のvcsとしてSubversionを使用しています。私は唯一の開発者であり、バグ追跡システムとしてbugzillaを使用しています。私はbugzillaとsvnをbugtraqプロパティを使って疎結合させていますので、私のコメントからbugzillaにリンクすることができます。現在私がやっていることは、Webサイト上での作業（拡張、ブレークフィックス、コンテンツの変更）をリクエストするたびです。bugzillaでバグ[xx]を作成し、bug [xx]というブランチを作成します。私が手動でベータサイトにブランチの変更をエクスポートした後、変更が確認され、確認された後、ブランチをトランクにマージして、バグを示す＃をbugtraqプロパティを使って返します。

これはかなりうまくいく.1つ以上の変更がある場合を除いて。私が10の作業要求に対して10のブランチを作成した場合、どのトランクがすでにトランクにマージされているのか、どのトランシーバがそうでないのかを簡単に知る方法を知りたい。私が狂ったように見えるmergeinfoプロパティを使用するはずです...

私はSubversionから切り替えたくないので、提案しないでください。

Answer 1

ブランチがトランクに再統合されたときにブランチを削除しないでください。フィーチャーブランチが再統合されたときにあなたがやろうとしていること（一般的な場合）。したがって診断は簡単です：分岐が存在する場合、再統合されていません。

Answer 2

あなたのワークフローはかなり良いようです。ただし、トランクにマージした後は、もはやバグブランチが必要ないので削除してください。そうすれば、開かれたバグとして枝の数が決まるだけです。

必要に応じていつでもブランチを戻すことができますが、問題が乱雑になることはありません。

Answer 3

各バグのブランチを作成することは、私の立場から見てよいことではありません。ベストプラクティスを分岐すると述べているように、あなたは、2つのケースでブランチを作成する必要があります

あなたの最後のリリースバージョンを保持したい場合は、あなたが新しい長い時間がかかる場合があり機能（機能ブランチ）と

を開発している

1. （リリースブランチ）。

2番目のブランチが必要なようです。それは明確に以下の絵を見てみ作成するには：

開発ブランチは、あなたのトランクのディレクトリの下に保たれている1（グリーンライン）です。リリースブランチ（赤い線）と呼ばれるブランチを作成し、リリースしたい変更をマージすることができます。この方法では、選択した変更のみがリリースされたバージョンになります。 1〜2週間以上かかる新機能を開発する場合は、機能ブランチ（青い線）を作成し、完了したら変更をマージして戻します。機能ブランチは、完了すると削除されることがあります。

私は、リリースブランチというブランチを1つだけ持つことを提案します。バグを受け取ったら、開発ラインを変更してください。テストがOKの場合、変更をリリースラインにマージすることができます。この方法で、必要な機能だけをリリースすることができます。さらに、リリースラインの履歴を見て、リリースラインにどの変更がマージされているかを知ることができます。