當您擁有一個長期存在的特性分支時，有兩種標準的方法可以讓它與您的主發布分支保持一定程度的同步，而無需將您的代碼實際放入主發布分支。
定期將特性分支與主發布分支重合，或者將主發布分支的變更反向合并到特性分支。
重新歸檔的方式是：
A - - - PRIMARY BRANCH
-1-2-3-特性分支
變成這樣：
A - - - PRIMARY BRANCH
-1'-2'-3'-功能分支
其中1' 2' 3'是原始1 2 3的重構版本。
合并后將其轉化為
A - - - PRIMARY BRANCH
-1-2-3-x - 功能分支
其中X是一個合并提交，它的父分支在PRIMARY和原FEATURE分支中都有。
重寫解決方案的一個缺點是，擁有特征分支副本的人現在擁有一組看似不相關的更改，因為他們的 1 2 和 3 與重寫后的 CL 不一樣。
rebase情況下的修改反映了主分支上 "就像你在rebase的時候做的那樣 "的修改。 這有一些很好的特性，就像你可以一次一次地回滾這些更改，看看它們在當前主分支中的表現如何。
問題在于
。是否有一種簡單的方法，使用標準的git工具一次完成這兩項作業，同時保持與原始特性分支的連接，以及一組代表針對當前主分支進行的CL？
A - - - PRIMARY BRANCH
1'-2'-3' -
-1-2-3----------- x - 特征分支
在這種情況下，X的內容與反向合并情況下的X的內容相同，只是它還說明原始特征分支是父CL。
由此，我們將得到重新發布的作業流程，但其他能夠訪問原始特性分支的人不會被拋棄 -- 如果他們針對上游FEATURE重新合并，git將完全理解正在發生什么。
A - - - PRIMARY BRANCH
1'-2'-3' -
-1-2-3----------- x - 功能分支
- 第三方
第三方CL有一個清晰的合并路徑，可以移動到feature BRANCH的頂端，而不是在
的情況下，它必須通過混亂的作業。A - - - PRIMARY BRANCH
1'-2'-3'--特征分支
-1-2-3--舊的特征分支
- 第三方
傳統的rebase。
uj5u.com熱心網友回復：
有沒有一種簡單的方法，使用標準的git工具來同時做這兩件事......
?
是的，你可以完全按照你的建議輕松地創建圖表：
git fetch
git checkout feature
git branch feature-old-copy # 創建一個 feature 的副本
git rebase origin/primary
git merge --strategy=our feature-old-copy
注意，最后的合并應該沒有任何效果；也就是說，這是一次毫無意義的合并，除了在分支中保留舊的提交ID集......
然而，IMHO認為你誤解了首先選擇 rebase 的主要原因。你的宣告：
在 rebase 情況下的修改反映了主分支上 "就像你在 rebase 時所做的那樣"。這有一些很好的特性，就好像你可以一次一次地回滾這些更改，看看它們在當前主分支中的表現如何。
這在合并中也是如此。(無論提交的內容是用 rebase 重寫的還是合并的，你都可以回滾，盡管 rebase 確實有一點好處*) rebase的主要好處是使歷史更清晰，沒有多個（通常）不必要的合并提交。舉個例子，當我使用 rebase 作業流程時，我通常會每天多次 rebase 到未來的目標分支。如果我的分支持續 2-3 天，我就會在我的分支上節省 10 次不必要的合并提交。在你建議的作業流程中，你并沒有真正捕捉到 rebase 的好處，因此，我認為它并不那么有用。
因此，是的，你可以這樣做，但我質疑這樣做的價值。
*在合并下恢復個別提交可能需要重新處理在合并時發生的沖突，而在 rebase 中，這些沖突已經被解決，更有可能干凈利落地恢復。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/308163.html
標籤：