1

私のチームはSVNを初めて使用しますが、各開発者が独自のブランチを作成するのを間違え、独自のブランチにコードを追加し始めたと思います。次に、すべてのブランチをトランクにマージする必要があります。これを行うための安全な方法はありますか？私はそれに取り組んできましたが、トランクにないファイルがブランチにあると、「ツリーの競合」エラーが発生し続けます。エラーを生成するいくつかのファイルを除いて、ほとんどのファイルが追加されます。

トランクは最初は空で、一度に1つのブランチをマージしようとしています。

TortoiseSVN1.7.9を使用しています。

これが現在の構造です。

projectFoo

    - branches
        - dev1
            - proj1

        - dev2
            - proj1

        - dev3
            etc...

    - trunk
        - <empty>
4

1 に答える 1

2

みんなが自分のブランチで働いていて、ブランチはお互いに何の関係もないので、あなたは楽しい時間を過ごすでしょう。これはプログラミングの意味でのマージではありません。真のマージとは、ブランチ「A」をブランチ「B」から分割することを意味します。したがって、2つのブランチには共通の祖先リビジョンがあり、「A」から「B」または「B」から「A」にマージされます。

あなたがする必要があることをする簡単な方法はありません。運が良ければ、すべての開発者が別々のコードで作業しているので、マージとは単にブランチをマージすることを意味し、実際の競合は発生しません。開発者が同じファイルで作業しているが、ブランチが異なる場合は、問題が発生します。

--ignore-ancestors祖先がないため、マージするときにパラメーターを使用する必要があります。それが私が言える唯一のことです。ただし、この問題を解決したら、分岐とマージを処理するためのより標準的な方法を使用するように解決できます。実際に使用するのに適した2つのパラダイムがあります。（他にもいくつかありますが、基本的には有毒です）：

  • 不安定なトランク：私の個人的なお気に入り。誰もがトランクから働きます。これは、神がSubversionを機能するように設計した方法です。分岐は必要な場合にのみ行われます。必要な場合の定義は少し曖昧です。基本的に、開発者をアイドル状態にしたくないので、必要なときに分岐します。

  • ストリーム開発：ストリーム開発では、統合ストリーム（通常はトランク）があり、開発者は作業を行うために_developmentストリーム（別名ブランチ）を作成します。開発ストリームは、開発者の個人的なワークスペース、アジャイルタスク、Jiraの問題、機能である可能性があります。基本的に、トランクからブランチを作成し、作業を行い、リベース（トランクから開発ブランチ ストリームへのマージ）、および_deliver（開発ストリームからトランクへのマージ）を行います。

ご覧のとおり、不安定なトランクでは、分岐がほとんど発生していないため、すべてが非常に単純です。そして、誰もがトランクから離れて作業するので、彼らは皆と少し良くコミュニケーションし、彼らはより小さな開発バイトを取ります。継続的インテグレーションと組み合わせるとうまく機能します。

いつ不安定なトランクに分岐しますか？通常、1つのリビジョンの仕上げを開始すると、開発者は現在のリビジョンで作業を開始し、次に次のリビジョンで作業を開始します。全員がリリース1.2に取り組んでいるとしましょう。誰もがトランクで作業します。一部の開発者が1.2での作業を終了し、リリース1.3で作業したい場合、リリース1.2でまだクリーンアップ作業を行う必要がある場合は、1.2リリースブランチをトランクから分岐します。

リリース1.3で作業している開発者は、引き続きトランクで作業します。リリース1.2を強化する開発者は、1.2ブランチで作業します。1.2 iをリリースする準備ができると、1.2リリースは1.2ブランチから実行され、1.2ブランチにタグ付けされます。パッチ/ホットフィックスリリース1.2.1が必要な場合は、1.2ブランチでも実行されます。

1.2ブランチで問題が見つかり、それがトランクの1.3リリースでも問題である場合、1.2ブランチはトランクからのものであるため、1.2での特定の変更をトランクに簡単にマージできます。

ストリーム開発は、統合ブランチ（別名トランク）に含めるものを選択できるため、アジャイル群集に支持されています。多くの場合、スプリントがほぼ完了するまで、ソフトウェアはトランクに配信されません。この方法が好きな人は柔軟性があるので好きですが、継続的インテグレーションはこの方法ではうまく機能しないため、私は好きではありません。さらに、通常、リリースの数日前まで適切なビルドはありません。

于 2012-12-05T05:14:34.310 に答える