5

CVSやSVNなどのリビジョン管理システムを初めて使用したとき、「トランク」、分岐、マージ、タグ付けの概念がよくわかりませんでした。私は今、これらの概念を理解し始めており、その背後にある重要性と力を本当に理解しています.

だから、私はそれを適切にやり始めています。またはそう私は思う...これは私がこれまでに理解していることです:コードの最新リリース/安定バージョンは /trunk/ に配置する必要がありますが、ベータ版または最先端のバージョンは、ベータごとに異なるディレクトリとして /branches/ ディレクトリ内に配置する必要がありますリリースし、リリースするとトランクにマージされます。

これは物事に対する見方が単純すぎるのでしょうか。皆さんはどのリポジトリレイアウトをお勧めしますか? 違いがある場合は、Subversion を使用しています。

4

4 に答える 4

5

詳細については、SO に関する次の 2 つの質問を参照してください。

于 2008-08-20T11:06:07.540 に答える
5

私がやっていること、そして通常は標準として見ていることは次のとおりです。

トランクには、開発のメイン ラインである不安定版が含まれている必要があります。リリースのリリース ブランチを作成する必要があります。

何かのようなもの：

/trunk (ここではバージョン 2.0 を開発しています) /branches/RB-1.0 (これは 1.0 のリリース ブランチです) /branches/RB-1.5

1.5 でバグを見つけたら、RB ブランチで修正してからトランクにマージします。

この本もお勧めです。

于 2008-08-20T11:10:16.360 に答える
1

Eric は、ソース管理の使用と組織のベスト プラクティスに関する優れた一連の記事を執筆しています。 第 7 章ではブランチについて説明します(もちろん、提案した /trunk/ および /branches/ ディレクトリを推奨しています)。

于 2008-08-20T11:28:43.193 に答える
1

私は長い間 Perforce を使用してきたので、私のコメントは少し Perforce 中心であるかもしれませんが、基本原則は適切な分岐を備えたすべての SCM ソフトウェアに適用されます。私は、分岐開発プラクティスを使用することを強く信じています。今から永遠にコードベースを表す「メイン」(別名「メインライン」) があります。目的は、これがほとんどの場合安定していることです。プッシュが発生した場合は、システムの現在の機能を反映するリリースをいつでもカットできます。それらの厄介なセールスマンは尋ね続けます....

開発は、MAIN から分岐した分岐で行われます (通常は、既存の dev 分岐から分岐したい場合があります)。MAIN から dev ブランチにできるだけ頻繁に統合して、あまりにも分岐しすぎないようにします。または、後でより長い統合期間の予算を立てることもできます。新しい機能を MAIN に統合するのは、それが次のリリースでリリースされることが確実な場合に限ってください。

最後に、リリースごとに異なるブランチを選択できる RELEASE 行があります。SCM ソフトウェアのラベル付け機能、およびメジャー リビジョンとマイナー リビジョンの違いに応じて、いくつかの選択肢があります。したがって、たとえば、すべてのポイント リリースのリリース ブランチを選択したり、メジャー リビジョン番号のみを選択したりできます。あなたのマイレージは異なる場合があります。

一般に、MAIN からリリースへの分岐はできるだけ遅くします。バグ修正と直前の変更は、後で MAIN に統合するために RELEASE に直接移動するか、すぐに統合をバックアップするために MAIN に移動することができます。厳格なルールはありません。最善の方法を実行してください。ただし、MAIN に送信できる変更がある場合 (たとえば、dev ブランチから、または MAIN の誰かによる「ちょっとした調整」)、前者を実行します。チームの働き方、リリースサイクルなどによって異なります。

たとえば、次のようなものがあります。

//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...

重要なプロジェクトでは、おそらく一度に多数の DEV ブランチがアクティブになります。開発が MAIN に統合されてコア プロジェクトの一部になったら、できるだけ早く古い DEV ブランチを削除してください。多くのエンジニアは、DEV ブランチを自分の個人的なスペースとして扱い、時間をかけてさまざまな機能に再利用します。これを思いとどまらせてください。

リリース後にバグを修正する必要がある場合は、対応するリリース ブランチで修正してください。バグが以前に MAIN で修正されている場合は、コードが MAIN で大幅に変更されていない限り、全体を統合します。修正は異なります。

コードラインを実際に差別化するのは、コードラインを管理するために使用するポリシーです。たとえば、どのテストが実行されるか、誰が変更の前/後をレビューするか、ビルドが壊れた場合にどのようなアクションが発生するかなどです。通常、ポリシー (したがってオーバーヘッド) はリリース ブランチで最も強く、DEV で最も弱くなります。ここには、いくつかのシナリオを説明した記事と、他の便利なものへのリンクがあります。

最後に、最初は単純な構造から始めて、必要に応じて追加の開発およびリリースのみを導入することをお勧めします。

それが役に立てば幸いです。あまり明白なことを述べていません。

于 2008-08-20T11:37:35.577 に答える