47

この方法でブランチをマージしやすくなり、競合が少なくなります。

トランクを新しいブランチにコピーし、機能ブランチとマージします。完了したら、新しいブランチをトランクにマージします。この手法は、MercurialやGitのリベースによく似ています。

以前は、トランクから機能ブランチに変更されたものをマージしていました。しかし、後で機能ブランチをトランクにマージすると、トランクからの一部が再びトランクにマージされ、多くの競合が発生しました。再統合マージの選択肢がありますが、それは私にはうまくいかなかったようです。

誰かが同様の破壊リベースをしますか？私は最近これを始めたばかりで、副作用は見られませんでした。これにより、予期しない問題が発生しますか？

4

6 に答える 6

39

一般的に言えば、リベースとは、フィーチャー ブランチを上流ブランチにマージして戻す前に、上流の変更をフィーチャー ブランチに組み込む行為です。

git では、ブランチが作成されてから行われた変更が最初に削除されてバッファリングされ、上流の変更が適用され、次にバッファリングされた変更が適用されるため、プロセスはさらに洗練されています。ここで重要なことは、トランクを機能ブランチにマージすることは、git 用語のリベースではなく、それ以上のことです。git アプローチには多くの利点がありますが、svn ではすべてのコミットをサーバーに保存する必要があるため (svn は分散されていません)、svn できれいに実装することはできませんが、svn で実行できます。

「svn rebase」(git の方法) は次のようになります。

  1. svn cp trunk feature
  2. 機能とトランクへのコミット
  3. svn cp trunk feature-rebase
  4. svn co feature-rebase
  5. cd feature-rebase
  6. svn merge feature
  7. svn commit
  8. svn rm feature
  9. svn mv feature-rebase feature
  10. (機能リベース WC に戻る)svn switch feature

その後、最終的にトランクの作業コピーで、svn merge --reintegrate feature

単にトランクを機能ブランチにマージすることとの違いがわかりますか? この例では、アップストリームの最新のトランクから始めて、機能からの変更をそれにマージします。

トランクへのコミットのいくつかは、別の機能ブランチのトランクへのマージから来る可能性があると想像してください。そのため、トランクに直接コミットすることをまったく推奨していません。

于 2013-09-30T02:09:22.790 に答える
7

SVNでリベースを実現する方法を教えてくれる巧妙なトリックがあればいいのにと思いますが、主にjdehaanが言及している手動のチェリーピッキングを必要とする複雑さのために、SVNでトランクを変更してブランチを手動で更新することは常に避けてきました。

代わりに私が一般的に行うことは、ブランチからトランクへの変更をマージし、ブランチを削除してから、トランクからブランチを再作成するという慣習に従うことです。これにより、機能ブランチを更新/リベースできますが、そのブランチからの以前の変更がトランクの一部になるという不幸な副作用が発生することがあります。このため、機能ブランチが安定して使用可能なポイントにある場合にのみこの方法に従いますが、さらに大きな目標を達成するために、その機能の作業を継続したいと思います。

私が好むのは、トランクの変更をブランチにマージしてブランチを更新しても、その後の再統合がそのブランチからマージされて、プロセス中にそれらのリベースされたリビジョンがプルされないことです。マージ情報のプロパティに基づいてこれを行うことは可能であるはずですが、jdehaanが述べていることと私が恐れていることによると、これを行うにはまだチェリーピッキングが必要です。

適切なリベースの実装では、分岐が別の分岐から作成される階段ケーシングの例も考慮に入れることができる必要があることに注意してください。

更新： Subversionのドキュメントによると、-reintegrateオプションを使用すると、Subversionは、ベースの変更をにもたらすために行われた可能性のある更新マージを考慮した方法で、ブランチで行われた作業を適切に再統合できるはずです。ブランチ。もちろん、これは技術的にはリベースとは少し異なりますが、使用法はリベースと呼ぶことができるほど十分に似ていると思います。

于 2011-02-09T18:28:18.257 に答える
4

私の会社では、次のアプローチを使用しています。

  1. 課題トラッカーの各タスク NK-$X に対して、個別のブランチ ブランチ/NK-$X があります。
  2. svn cp トランク ブランチ/NK-$X でタスクの作業を開始します
  3. 変更をトランクに直接コミットすることはありません。スケジュールされた更新 UPDNK-$X ごとに、個別のブランチ/UPDNK-$X があります。更新直前に svn cp trunk branchs/UPDNK-$X で作成しています。
  4. タスク NK-$X が UPDNK-$Y の更新のためにスケジュールされている場合、UPDNK-$Y ではなくブランチ/NK-$X をマージします。それは cd UPDNK-$Y; です。svn merge -r start:HEAD ブランチ/NK-$X
  5. UPDNK-$Y の準備ができたら、トランクにマージします。それは cd トランクです;svn マージ -r 開始:HEAD ブランチ/UPDNK-$Y

タスク NK-$X が 1 反復サイクルよりも長く続き、更新が必要な場合、トランクを NK-$X にマージすることは決してありません。自分で書いたものだけをブランチにコミットするというルールがあります。これにより、すべてが簡単になります。代わりに、次のことを行います。

cd NK-$X
svn log
//let L = the number of the last changeset to this branch changeset
//let F = the number of the first changeset to this branch
svn rm branches/NK-$X 
svn cp trunk branches/NK-$X 
svn up
svn merge -r F:L branches/NK-$X@L 
svn ci -m 'refereshed'

このように、branchs/NK-$X の変更ログを見ると、開発者が実際に行った変更のみが表示されます。

更新: 上記のワークフローは自動化できるため、github: svn rebaseでプロジェクトを開始しました。

于 2012-11-22T07:17:54.787 に答える
0

私はこのアプローチを使用しています：

リベースでは、再度マージするときにリベースされたリビジョンを引き継がないように注意する必要があります。マージに関しては、チェリー ピッキングを行います。リベースの変更セットではなく、何か新しいものを実装するフィーチャー ブランチのリビジョンのみを選択します。その後、正常に動作するはずです。コメント: reintegrate ブランチを何かに使用したことを思い出せません。非常に単純なユースケースのみを対象としていると思います。

あなたの新しいアプローチでは、必要に応じてトランクから機能ブランチへのリベースを処理する方法が説明から明確ではありません。リベースを完全に禁止しますか? svn での分岐は安価な操作であるため、これもオプションになる可能性があります。

于 2010-07-05T05:13:32.387 に答える