私は理論を知っていますが、プロジェクトの実用的な観点からsvnはどのように使用されますか？たとえば、変更または追加される機能を備えたWebサイトがあります。どのような場合に新しいトランク、ブランチ、タグが使用されますか？
4 に答える
2
これらの2つの記事を見てください：
http://www.snuffybear.com/ucm_branch.htm
http://www.vance.com/steve/perforce/Branching_Strategies.html
SnuffyBearからのリンクでは、採用したいと思われる戦略について詳しく説明していますが、他の記事では、リリースごとのブランチなどの他の戦略について説明しています。各記事では、各戦略の長所と短所について概説しています。
于 2011-04-06T14:40:50.463 に答える
2
異なる組織は非常に異なることを行います。上で Alex が提供する解決策は一般的なものですが、自分のブランチに到達した後で、自分のブランチと競合している他のブランチしか発見できないという問題が発生します。これにより、人々はしばらく見ていないものの競合をデバッグする必要があります。
私が遭遇したもう 1 つの一般的なアプローチは、すべての開発をトランクで行い、開発者にすべてのコミットを小規模でスタンドアロンのコミットにすることです。機能を追加してデフォルトで非表示にするさまざまな方法がありますが、開発コピーではオンになっています。それらを使用します。このアプローチには開発者の注意が必要ですが、存続期間の長いブランチ間の競合を管理する手間を省くことができます。
アレックスのソリューションを使用する多くの人々は、「それは小さなチーム以外では決してうまくいかない!」と飛び跳ねます。それに対して私は、小規模なチームに問題はなく、その生産性は通常、大規模なチームができることをはるかに上回っていると答えます。そして、その戦略は、たとえば Google が使用するなど、開発者に規律があれば拡張できます。その戦略を使用する実際のプロジェクトを見たい場合は、http://llvm.org/をご覧ください。
そして、いくつかのアドバイス。Alex の戦略に従いたい場合は、svn の代わりに git を使用することを強くお勧めします。svn よりもはるかに適切にブランチを処理します。私が提案する戦略に従いたいが、あなたのチームが信頼できる人だけの小さなチームではない場合は、http://code.google.com/appengine/articles/rietveld.htmlのようなコード レビュー ツールを使用して、発生する可能性のある明らかな問題を減らします。
于 2011-04-06T14:34:09.517 に答える
1
私の謙虚な観察: ブランチのマージは怖いものです。多くの場合、異なる開発者による変更は完全に分離されているため、スムーズにマージされます。しかし、忙しいプロジェクトでは、変更が競合する場合があります。運が良ければ、SVN は競合を認識し、マージ時にエラーを表示します。運が悪いと、SVN はそれをキャッチできず、コンパイルに失敗します。いずれにせよ、誰かが変更をまとめる方法を考え出さなければなりません。時にはこれは明白で簡単です。しかし、何をすべきかを理解するために、変更を行った開発者を集めなければならないことが何度もありました。
非常に運が悪いと、SVN もコンパイラも問題を認識せず、競合する変更が本番環境に移行し、プログラムが正しく動作しなくなります。
この観察から、次の 2 つの結論に至ります。 (a) 分岐をできるだけ少なくする。より正確には、マージをできるだけ少なくする戦略を立てます。(b) まだテスト中にコードをマージします。
しばらくの間、私の会社には、各プロジェクトに独自のブランチがあり、そのブランチからテストするというブランチ戦略がありました。本番環境にデプロイする準備ができたら、そのリリースに含めるすべてのブランチをマージし、コンパイルしてデプロイしました。 . これは本当に悪い考えであることが判明しました。デプロイの前日に誰かがマージの競合を解決しようとしていて、マージの結果はテストされていませんでした。多くの微妙なバグが本番環境に忍び込みました。
しばらくの間、この戦略を使用しました。ほとんどの開発はトランクで行われます。リリースがテストグループに引き渡される準備ができたら、ブランチを剥がします。その後、次のリリースの作業がトランクで進行します。現在のリリースに対するバグ修正はブランチで行われ、このブランチの変更は定期的にトランクにマージされます。場合によっては、同時に 3 つのリリースに取り組む必要がありました。つまり、1 つのリリースはテスト中で、もう 1 つのリリースはテストの準備が整い、次のリリースに着手する必要がありました。その場合、テスト ブランチ、現在のリリース用のトランク、および次のリリース用の「pre」ブランチがあります。現在のリリースがテスト グループに送られると、「pre」ブランチをトランクにマージし、それが現在のリリースになりました。
私たちは最近、少し異なる戦略の実験を始めました。リリースがテスト中の場合でも、別のブランチをピールオフします。ただし、テストで得られた修正はすべてトランクで行われ、それらの修正はトランクからテスト ブランチにマージされます。これは、すべての開発がトランクで行われ、マージは常にトランクから別の場所に行われることを意味します。これには 2 つの大きな利点があります。1 つは、開発者は常にトランクを使用してテストしているため、トランクのコードが優れているという確信が持てます。テスト グループはリリース ブランチに対してテストを行うため、リリース ブランチが優れていると確信しています。つまり、両方のブランチがテストされるという確信があります。ブランチに変更を加えてからトランクにマージする場合。誰かがそのマージの結果をテストするという保証はほとんどありません。二、トランクには常に、すべてのモジュールの完全な「責任」履歴があります。ブランチからトランクにマージするとき。トランクの履歴は、実際に変更を行った人ではなく、ブランチからのすべての変更をマージを行った人に帰するものであり、コメントは有益でない「brach xyz からマージされた」となる傾向があります。トランクからブランチにマージすると、ブランチに「間違った」人物と有益でないコメントが表示されるようになりますが、トランクには良い履歴があります。枝を追いかけるのではなく、歴史をたどる場所が 1 つあります。
于 2011-04-06T15:07:33.213 に答える
1
「安定した」非常にマイナーな変更 (おそらく小さなバグ修正) が行われる単一のトランクで、ビルドが壊れることはありません。
新しい機能や大きな変更にはブランチを作成する必要があります。ブランチが稼働している間は、トランクの変更に合わせてブランチを最新の状態に保つ必要があります。
新しい機能が完成したら、ブランチをトランクにマージし直してから、ブランチを削除できます。
タグはリリース用です。例: v1.2
于 2011-04-06T14:14:39.437 に答える