合并：Hg / Git與SVN我經常讀到Hg（和Git和......）在合并方面比SVN更好但是我從未見過Hg / Git可以合并SVN失敗的地方（或者SVN需要人工干預的地方）的實際例子。您可以發布一些分支/修改/提交/ ....-操作的逐步列表，顯示SVN在Hg / Git愉快地移動時會失敗的位置嗎？實用，非常特殊的情況請...一些背景：我們有幾十個開發人員在使用SVN進行項目，每個項目（或一組類似項目）都在自己的存儲庫中。我們知道如何應用發布和功能分支，所以我們不會經常遇到問題（即，我們一直在那里，但我們已經學會克服Joel的問題 “一個程序員給整個團隊造成創傷”或“需要六個開發人員兩周才能重新整合分支機構”）。我們的發布分支非常穩定，僅用于應用錯誤修正。我們的中繼線應該足夠穩定，能夠在一周內創建發布。我們還有一些開發人員或開發人員可以使用的功能分支。是的，它們在重新集成后被刪除，因此它們不會使存儲庫混亂。;）所以我仍然試圖找到Hg / Git優于SVN的優勢。我很想獲得一些實踐經驗，但是還沒有任何更大的項目我們可以轉移到Hg / Git，所以我一直在玩那些只包含一些組成文件的小型人工項目。而且我正在尋找一些你可以感受到Hg / Git令人印象深刻的力量的案例，因為到目前為止我經常讀到它們但卻未能自己找到它們。
3 回答
慕少森
TA貢獻2019條經驗 獲得超9個贊
我自己并沒有使用Subversion，但是從Subversion 1.5的發行說明：合并跟蹤（基礎）看起來，在GID或Mercurial等全DAG版本控制系統中，合并跟蹤的工作方式有以下不同之處。
合并主干到分支不同于合并分支到主干：由于某種原因合并主干到分支需要
--reintegrate選項svn merge。在像Git或Mercurial這樣的分布式版本控制系統中，主干和分支之間沒有技術差異：所有分支都是相同的（盡管可能存在社會差異）。在任一方向上合并都以相同的方式進行。
您需要提供new
-g（--use-merge-history）選項svn log并svn blame考慮合并跟蹤。在Git和Mercurial中，在顯示歷史記錄（日志）和責備時會自動考慮合并跟蹤。在Git中，您可以請求僅跟隨第一個父母
--first-parent（我猜Mercurial也存在類似選項）以“丟棄”合并跟蹤信息git log。據我所知，
svn:mergeinfo屬性存儲有關沖突的每路徑信息（Subversion是基于變更集的），而在Git和Mercurial中，它只是可以擁有多個父級的提交對象。Subversion中合并跟蹤的“已知問題”小節表明重復/循環/反射合并可能無法正常工作。這意味著在以下歷史記錄中，第二次合并可能不會做正確的事情（'A'可以是主干或分支，'B'可以分別是分支或主干）：
* --- * --- x --- * --- y --- * --- * --- * --- M2 < - A. \ / / - * ---- M1 --- * --- * --- / < - B.
在上述ASCII藝術被破壞的情況下：分支'B'在修訂版'x'處從分支'A'創建（分叉），然后分支'A'在修訂版'y'處合并到分支'B'中合并'M1'，最后將分支'B'合并為分支'A'作為合并'M2'。
* --- * --- x --- * ----- M1 - * --- * --- M2 < - A. \ / / \ - * --- y --- * --- * --- / < - B.
在上述ASCII藝術被破壞的情況下：分支'B'在修訂版'x'處從分支'A'創建（分叉），它在'y'處合并為分支'A'作為'M1'，稍后再次合并為分支'A'作為'M2'。
Subversion可能不支持縱向交叉合并的高級案例。
* --- b ----- B1 - M1 - * --- M3 / / / / \ X / \ / \ / \ - B2 - M2 - *
Git在實踐中使用“遞歸”合并策略處理這種情況。我不確定Mercurial。
在“已知問題”中，警告合并跟蹤不能與文件重命名一起使用，例如，當一方重命名文件（并且可能修改它）時，第二方修改文件而不重命名（在舊名稱下）。
Git和Mercurial在實踐中都處理了這樣的情況：Git使用重命名檢測，Mercurial使用重命名跟蹤。
HTH
明月笑刀無情
TA貢獻1828條經驗 獲得超4個贊
在沒有談到通常的優點（離線提交，發布過程 ......）這里是一個我喜歡的“合并”示例：
我一直看到的主要場景是一個分支，其中...... 實際開發了兩個不相關的任務
（它從一個功能開始，但它導致了另一個功能的開發。
或者它從一個補丁開始，但它導致了開發另一個功能）。
如何只合并主分支上的兩個功能之一？
或者，您如何在自己的分支中隔離這兩個功能？
您可以嘗試生成某種補丁，問題是您不再確定可能存在的功能依賴關系：
補丁中使用的提交（或SVN修訂版）
另一個承諾不是補丁的一部分
我認為Git（以及Mercurial）建議使用rebase --onto選項來重組（重置分支的根）部分：
- x - x - x (v2) - x - x - x (v2.1) \ x - x - x (v2-only) - x - x - x (wss)
你可以解決這種情況，你有v2的補丁以及新的wss功能：
- x - x - x (v2) - x - x - x (v2.1) |\ | x - x - x (v2-only) \ x - x - x (wss)
，允許您：
單獨測試每個分支以檢查所有內容是否按預期編譯/工作
僅合并您想要的主要內容。
我喜歡的另一個功能（影響合并）是能夠壓縮提交（在尚未推送到另一個倉庫的分支中）以呈現：
更清潔的歷史
更一致的提交（而不是function1的commit1，function2的commit2，function1的commit3 ......）
這確保合并更容易，沖突更少。
- 3 回答
- 0 關注
- 661 瀏覽
添加回答
舉報
0/150
提交
取消