我覺得這種方式更容易合併分支少衝突：顛覆重建？
複製樹幹一個新的分支，具有特性分支/ s的合併。完成後，將新分支合併回主幹。這種技術很像mercurial和git rebasing。
我用來合併任何從主幹到特徵分支/ s的變化。但後來當我將功能分支合併回主幹時，主幹中的一些東西會再次合併回主幹，導致很多衝突。有重新融入合併的選擇，但它似乎不適合我。
有沒有人做類似的顛覆rebasing？我剛剛開始這樣做，並沒有看到任何副作用。這會造成任何未解決的問題嗎？
我使用這種方法：
隨着基礎重建你要小心不要拿重訂基期的修改，當您再次合併過來。在合併時，請執行櫻桃選擇：僅選擇實現新功能的功能分支上的修訂版本，而不是重新綁定變更集。那麼它應該工作得很好。評論：我永遠不會記得使用重新合併分支的東西。我認爲它只適用於非常簡單的用例。
在您的新方法中，從描述中不清楚如何處理從主幹到您的功能分支的重新綁定（如果需要的話）。你想徹底禁止rebasing？由於在svn中分支是一個便宜的操作，所以這也是一個選項。
以下是我的程序： 1. trunk-> f1，f2（功能分支） 2.當f1，f2完成時，trunk-> version分支（用於整合） 3.將f1，f2合併到版本分支（VB ） 4.測試VB;將f1，f2的修復合併到VB;繼續這一步驟，否則重複2到3 5.當VB完成後，將它合併回中繼線，釋放它。 – 2010-07-14 01:58:07
我希望我有一個聰明的竅門，告訴你如何在SVN中實現rebasing，但是我總是避免手動刷新SVN中樹幹變化的分支，這主要是因爲jdehaan提到手動櫻桃採摘的複雜性。
我通常會這樣做的做法是遵循將分支上的更改合併到主幹，刪除分支，然後從主幹重新創建分支的做法。這使我可以刷新/重新綁定我的功能分支，但有時會帶來不幸的副作用，即此分支的任何先前更改現在都是主幹的一部分。出於這個原因，我只有在功能分支處於穩定可用點時才遵循這種做法，但我仍然希望繼續使用該功能以進一步完成一些更大的目標。
我更喜歡的是通過將樹幹變化合並回分支來刷新樹枝，而不會導致該分支的後續重新集成合並，以便在此過程中拉取這些重新摺疊的版本。應該可以根據merge-info屬性來做到這一點，但根據jdehaan州和我擔心的是，這樣做仍然需要櫻桃採摘。
請注意，適當的重新佈局實現應該也可以考慮樓梯套房的例子，其中一個分支由另一個分支構成。
更新：根據看來，使用--reintegrate option時顛覆應能正確地重新融入社會的方式，頭腦可能已做任何可能刷新合併，使基地的一個分支所做的工作Subversion的文檔變成分支。當然，這在技術上與基礎設施稍有不同，但我認爲它在使用上足夠相似，因此可以稱之爲重新裝訂。
你必須在顛覆中合併上游時使用* - reintegrate *。這一切都伴隨着w/svn 1.5合併跟蹤，並且合併了*可能*，相比之下，舊的頭疼追蹤哪些變更集合已經被合併到了一個分支中。與hg/git提供的實現相比，它仍然是非常原始的實現，而不是實際上成爲重新綁定過程的一部分。這更多的是當你完成功能或發佈分支。 – quickshiftin 2014-09-28 15:18:33
在我的公司，我們使用以下方法：
如果碰巧任務NK-$ X持續時間超過一個迭代週期，因此需要刷新，我們永遠，永遠，切勿將中繼線合併到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/[email protected]
svn ci -m 'refereshed'
這樣，每當你看看分行的更新日誌/ NK-$ X你看到的唯一變化實際上是由開發商進行。
更新： 由於上述工作流程可以自動的，我已經開始在GitHub上一個項目：svn rebase。
一般而言，重新綁定是在將特徵分支合併回上游分支之前將上游更改合併到特徵分支中的行爲。
在git中，這個過程更加複雜，因爲創建分支後所做的更改首先被取出並緩存，應用上游更改，然後應用緩衝更改。這裏的外賣將主幹合併成一個功能分支並不是用git來表示的rebase，更重要的是它。 git方法有許多優點，但不能在svn中很乾淨地實現，因爲所有提交必須存儲在服務器上（svn不是分佈式的），但是它可以在svn中完成和。
的 'SVN變基'（Git的方式）可能是這個樣子
svn cp trunk featuresvn cp trunk feature-rebasesvn co feature-rebasecd feature-rebasesvn merge featuresvn commitsvn rm featuresvn mv feature-rebase featuresvn switch feature，svn merge --reintegrate feature
你看，從簡單的區別將主幹合併到特徵分支？你首先從上游的最新版本，在這個例子中，然後合併來自特徵的變化。
想象一下trunk上的一些提交可能來自另一個特性分支到trunk的合併，所以我根本不主張直接提交trunk。
我一直在拖着腳，但決定在主題上貼出[一篇文章]（http://quickshiftin.com/blog/2013/09/svn-rebase-git-way/）徹底的解釋。 – quickshiftin 2013-09-30 03:23:23
我是一個vcs noob。我很好奇：這會是什麼樣的衝突呢？如果通過trunk @ r2將trunk @ r1合併到分支中，並將結果合併回trunk，則不應因trunk而發生任何更改。你能給個例子嗎？ – 2012-08-08 18:54:42
你在你的問題中建議的是正確的解決方案;-)它應該按預期工作，我看不到任何副作用。 – ymajoros 2012-08-08 08:31:37