我們將把我們的 TFS/TFVC 存盤庫遷移到 Git。在 TFVC 中，我們曾經有一個基于主干的開發，具有持久的發布維護分支。發布分支上的錯誤修復必須合并回主干。有時，較小的功能必須從主干轉移到發布分支。在 TFVC 中，我們通過“合并”從一個分支到另一個分支的單個（或一小組）變更集來做到這一點。生成的變更集被標記為“合并”，盡管我不完全知道這對 TFVC 意味著什么，尤其是考慮到未來的合并操作。
所以我想象分支圖看起來像這樣：（盡管請注意 TFVC 從不顯示任何圖形）
-A--B--C---D--E--F--- trunk
\ / \
G--H--I--J---K--L- release-x
（這里的發布分支是從 A 創建的，I->D 是一個錯誤修復合并，E->K 是一個功能轉發）但也許我錯了。在這種情況下，有人可以解釋 TFVC 合并變更集的真正作用嗎？
有人告訴我，在 Git 中一種等效的做法是挑選個人提交。但是，在生成的分支圖中，我沒有看到在cherry-pick 提交之后分支之間的任何鏈接。我知道櫻桃采摘在技術上不是合并操作，因此分支之間的歷史關系不會結轉。有什么我想念的嗎？有沒有更好的方法將如此小的提交從一個分支轉移到另一個分支，但仍然保留一些合并資訊？我不想合并整個分支。例如，變更集 B、C 或 H 必須與其他分支保持隔離。
uj5u.com熱心網友回復：
當 Cherry pocking 時，您可以添加-x選項讓 git add 一條訊息到每個cherry-picked 提交的提交訊息：
-x在記錄提交時，在原始提交訊息中附加一行“(cherry pick from commit ... )”，以表明此更改是從哪個提交中挑選出來的。這僅適用于沒有沖突的櫻桃選擇。如果您是從私人分支機構挑選的，請不要使用此選項，因為這些資訊對收件人毫無用處。另一方面，如果您在兩個公開可見的分支之間進行挑選（例如，將修復程式反向移植到開發分支的舊版本的維護分支），則添加此資訊可能很有用。
這是你得到的最接近的。精心挑選的提交記錄為她目標分支上的新提交，而不是作為前向集成的反向。
Git 不執行“部分合并”，因為 git 將作業樹的狀態存盤為“版本”。相反，TFVC 存盤單個圖塊的作業區版本。
你看到的是兩種截然不同的東西。
在 TFVC 中，您會看到一個分支圖，該圖通過具有已定義父分支的分支物件明確定義。這些分支之間的每個集成都是可視化的，因為合并存盤了哪些檔案被合并，哪些變更集是該合并的一部分，以及這些合并的分支關系。TFVC 中的變更集（最接近 git 中的提交）也是非常不同的事情。一方面，一個變更集可以跨越多個分支，甚至是存盤庫，并且一個變更集包含對檔案的 1 個或多個更改。
在 Git 中，分支只是一個指向提交圖中某處提交的特殊指標。計算父系（基于提交圖）并且分支可以自由合并，而無需考慮預先配置的層次結構。可視化顯示了提交之間的關系，而不是分支之間的關系。一種特殊型別的提交，即合并，存盤從 2 個或更多其他提交的基礎上創建新提交的時間。存盤與這些提交的關系，而不是恰好指向這些提交的分支的名稱。提交存盤對作業樹的更改。一個或多個分支可能指向該提交。
由于cherry-pick 將提交樹中一個分支上的更改重播到另一個分支上，因此它不會被記錄為多組提交鏈接在一起的合并。相反，它被記錄為恰好具有相同差異的新提交（如果您需要進行沖突解決，甚至可能不是這樣）。
通過添加-x標志，關系存盤在評論中。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/372628.html