2

私はSVNを使用して他の開発者と協力しています。私は SVN の初心者であり、SVN の最適な使用方法をよりよく理解したいと考えています。

現時点では、次のものがあります。

                            __ branch developer 1
Project 1                 /___ branch developer 2
      |                  /____ branch developer 3
      |____ branches---- \____ branch developer 4
      |                   \___ branch developer 5
      |____ tags           \__ branch developer 6
      |
      |____ trunk

開発を始める前に、彼らは私に次のことを求めました。

  1. ブランチを更新する
  2. 他のブランチからブランチをマージして競合を解決するため、dev1、dev2、dev3 などからマージする必要があります... 作業をコミットします

さて、私の質問は...これは正しいアプローチですか？非常に多くのマージを行うには多くの時間がかかります...毎回。それとも、すべての開発者に対して 1 つのブランチのみを使用する必要がありますか? 私は SVN に本当に慣れていないので、何か間違ったことをしたくありません...だから、私を正しい方向に導く手助けをしてくれることに本当に感謝しています。

4

4 に答える 4

3

いいえ、SVN を使用する正しい方法ではありません。すべての開発者が独自のブランチを持つ必要はありません。

通常、誰もがトランクで作業します。開発に時間がかかり、他の開発者の邪魔を避けるためにトランクで実行してはならない機能がある場合は、特定の機能ブランチが作成されます。トランクからの変更は定期的にこの機能ブランチにマージされ、機能が独自の機能ブランチで完全に開発されると、ブランチはトランクに再統合され、削除されます。

誰もが常に他のブランチからマージしなければならない場合、それはトランクですべて作業するのと何ら変わりはありませんが、それははるかに面倒です。とにかく、2 人または 3 人以上の開発者には拡張できません。

上記のすべてを詳細に説明している無料のSVN ブックを読み、同僚と話し合って、従来のベスト プラクティスを採用することをお勧めします。

于 2012-07-05T09:31:42.800 に答える
2

個人的には、上記の現在の実装は非常識だと思います。現在、7 つのブランチ (各開発者に 1 つ) があり、作業を開始する前にそれぞれ 7 つのマージが必要です。

チームに参加する開発者が増えるとすぐに、マージ戦略は非常に面倒になり、エラーが発生しやすくなります。自分で開発を開始する前に、X 個のブランチで競合を編集しなければならないというリスクがあります。

すべての開発者にリポジトリのトランクで作業してもらいます。1 つのリポジトリ ディレクトリのみを処理する場合は、競合の解決とマージの管理が容易になります。

理想的には、完了までに最大でも数日しかかからないアジャイル ワークフロー (小さな一口サイズの管理可能な作業の塊) で作業したいと考えています。それよりも長いプロジェクトは、チームの他のメンバーのワークフローを混乱させないように、純粋にコードと広範なリファクタリングをトランクから分離するために、独自のブランチ フォルダーに値する可能性があります。

その大規模なタスクが完了すると、ブランチ フォルダーが 1 つだけトランクにマージされます (作業が完了すると、他の開発者によって常に更新されます)。

ソース管理システムは、開発ワークフローを複雑にするのではなく、簡単にするために使用する必要があります。

于 2012-07-05T09:38:03.933 に答える
0

他の答えがあなたに言うように：このアプローチは単に頭がおかしいです。最終的に作業をコミットする前に、さまざまなブランチからマージする時間を無駄にします。

これとは別に、開発者ごとに物事を分割したい場合は、mercurialやGitなどの分散VCSを使用してみませんか？

SVNを学ぶ必要がある場合（そしてまだ甘やかされていない場合）、MercurialまたはGitも学ぶことができます。そして、切り替えるのには十分な理由があります。

私は2年前にGitのSVNを削除しましたが、1日後悔していませんでした。代わりに、安価な分岐、作業中のマージ、マスターに入る前のリワークコミットなどを楽しんでいます。

誰もがローカルで作業します。物事をマージしてmaster（別名trunkSVNで）戻すと、開発者はマージしてから中央リポジトリにプッシュします。which-developer-shall-work-on-which-branchについて考える必要はありません。

分岐に関しては、成功したGit分岐モデルに関する非常に人気のある記事が1つあります：http：//nvie.com/posts/a-successful-git-branching-model/

たぶん、あなたは同僚に、切り替えが彼らの仕事にとって本当の利益になるだろうと納得させることができるでしょう。私はGitを使用しているにもかかわらず、手動でマージすることを主張するものを使用しています。作業の同期には、毎週2〜3時間かかります。たった2人の作品。より多くからマージする場合は、より適切に使用できるようになるまでにさらに多くの時間がかかります。

于 2012-07-05T10:35:39.413 に答える
0

私はあなたの戦略が現在非常識であるという他の人に同意します! ;)

個人的には、トランクを安定した「ライブ」バージョンとして保持し、すべての開発を 1 つのブランチに保持することを好みます。これにより、すべての開発者が同じブランチで作業し、機能またはプロジェクトの準備が整ったときにマージするだけで済みます。ライブであり、分岐してからトランクが変更されていないことがわかります。

上記のオプションは機能しますが、トランクで何かが変更されるたびにブランチを更新し続ける必要があり、競合 (およびトランクがライブ コードの場合はサイト/製品が壊れる) の可能性が高まるのではないかと心配します。

于 2012-07-05T10:23:47.863 に答える