web-dev-qa-db-ja.com

Subversionブランチの再統合

ブランチがトランクに再統合された場合、そのブランチは事実上停止していますか？

再統合後にブランチに変更を加え、後日それらをトランクにマージできますか？

svnmergebranch
68
Aaron Smith

技術的にはできますが、ブランチはデッドでもディセーブルでもありませんが、再統合後にブランチからトランクにマージすることは推奨されません。

その理由についての完全な議論はここにあります： Subversion merge reintegrate

基本的に、変更を再びトランクにマージすることが可能ですが、再統合により、再統合操作の前にトランクからブランチに強制的にマージされるため、Subversion 1.5で非常に問題となるReflective/Cyclic Mergeに直面します。
記事によると、再統合後すぐに再統合されたブランチを削除し、代わりに同じ（または異なる）名前で新しいブランチを作成することをお勧めします。

これは既知のSubversionの動作であり、将来のバージョン（おそらく1.6）で対処される予定です

79
Pini Reznik

実際には、--record-onlyコミットによって作成されたリビジョンのブランチへのトランクからの--reintegrateマージを行う必要があります。

$ cd trunk
$ svn merge --reintegrate ^my-branch 
$ svn commit

Committed revision 555. 
# This revision is ^^^^ important

そして今、あなたはそれを記録します

$ cd my-branch
$ svn merge --record-only -c 555 ^trunk 
$ svn commit

あなたは今ブランチを維持して幸せです

詳細は第4章分岐とマージ、高度なマージにあります。

17
krico

ブランチからトランクに再統合したら、次の2つのいずれかを実行する必要があります。

  • ブランチの削除 。これは最も簡単ですが、ブランチの履歴を確認するのが難しくなります。

  • 再統合コミットをマージしないようにブランチに伝えてください 。トランクに再統合し、リビジョンXとしてコミットする場合、ブランチで次のコマンドを実行できます：svn merge --record-only -c X url-to-trunk。ただし、マージ自体以外にコミットの一部として変更を加えた場合は、これを行うべきではありません。他の変更がブランチに戻ることはありません。

8
JW.

誰かがブランチに複数回変更を加えた場合（1.5より前）に変更をマージするためのアドバイス：マージしたリビジョンを覚えておいてください！リビジョン番号をor（これは簡単です）タグを作成のどこかに書き留めてください。 （もちろん後で見つけることができますが、それはPITAです。）

例：

次のようなリポジトリレイアウトがあります。

/your_project
  /trunk
  /branches
  /tags

Webアプリケーションであり、リリースを計画しているとします。タグを作成し、そこから（またはトランクから）バグ修正を行うブランチを作成します。

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0

この方法で、トランクに新機能を統合できます。すべてのバグ修正はバグ修正ブランチ内でのみ発生し、各リリースの前に現在のバージョンのタグを作成します（バグ修正ブランチから）。

かなりの量のバグ修正を行い、それらを本番サーバーにリリースし、現在のトランクにこれらの機能のいずれかが必死に必要であると仮定しましょう。

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2

これで、1.0.0から1.0.2までの変更をトランクに統合することができます（作業コピーにいる場合）：

svn merge http://rep/your_project/tag/1.0.0 http://rep/your_project/tag/1.0.2 .

これは覚えておくべきことです。トランクで1.0.0と1.0.2の間の変更を既にマージしました。現在の製品リリースにさらに変更があると仮定しましょう。

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4

これで、トランクから新しいバージョンをリリースする準備ができましたが、バグ修正の最後の変更はまだありません。

svn merge http://rep/your_project/tag/1.0.2 http://rep/your_project/tag/1.0.4 .

これで、トランクでall変更がマージされ、リリースすることができます（最初にテストすることを忘れないでください）。

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
    /1.1.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4
    /1.1.0
3
Mauli

誰もがすでにここで言っているように：ブランチは死んでおらず、ブランチへのコミットは問題なく続行できます。

マージ後にブランチを強制終了したい場合もあります。唯一確実な解決策は、ブランチを削除することです。欠点は、たとえば歴史的な理由でブランチを見たい場合、ブランチを再度見つけるのが難しいということです。そのため、多くの人々は「重要な」ブランチを横に置き、それらを変更しないことに同意します。ブランチにデッド/読み取り専用のマークを付ける方法があればよいので、今後の通知まで誰もコミットできないようにします。

2
Alexander

いいえ、ブランチはまだ生きていますが、その時点では、トランクとまったく同じです。ブランチで開発を続ける場合、後でトランクと自由に再マージできます。

2
Ben Hoffstein

ブランチからトランクへ、またはトランクからブランチへは、何度でもマージできます。

1
Chris Marasti-Georg

まず、Subversion 1.7以前を使用している場合は、Subversionクライアントとサーバーをアップグレードする必要があります。非常に古いSubversionリリースを使用する理由はありません。 2016年現在、現在のバージョンはSubversion 1.9です。 SVN 1.8もサポートされるようになり、バグ修正が引き続き提供されます。

あなたが尋ねる問題はSubversion 1.8で解決されました。 SVN 1.8以降、--reintegrateオプションは廃止されました。統合の再統合が自動で実行されるようになりました。 改善に関連するSubversion 1.8リリースノートエントリ を参照してください。

読む SVNBook 1.8 |ブランチの再統合 ：

ブランチをトランクに再統合した後、ブランチを削除しないことを選択した場合、トランクから同期マージを実行し続けてから、ブランチを再度統合することができます。これを行うと、最初の再統合後にブランチで行われた変更のみがトランクにマージされます。

...

この機能ブランチの再利用をサポートしているのはSubversion 1.8のみです。以前のバージョンでは、機能ブランチを複数回再統合する前に特別な処理が必要です。詳細については、この章の以前のバージョンを参照してください。 http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

1
bahrep