使用遠程存盤庫時，您可以選擇合并和變基，但是在閱讀了它之后，我不知道為什么或何時會使用變基。似乎合并是總體上更好的選擇，即使它們都有優點和缺點。我只能考慮合并是可行的方案。所以我想知道什么時候變基更好。
uj5u.com熱心網友回復：
tl;dr合并功能分支，rebase 更新。
如果要合并功能分支，請合并。實際上，強制與--no-ff(no-fast-forward)合并。這給歷史留下了一個“功能氣泡”，顯示了哪些提交被分組到一個分支中。你可以看到這個git log --graph。
A - B --------- M - H <-- master
\ /
E - F - G
如果你變基，你只會得到一個平坦的歷史。
A - B - E - F - G - H <-- master
有些人喜歡這種平坦的歷史，它更簡單，但它確實丟失了無法恢復的資訊。有些人喜歡壁球合并的原因。
A - B - S - H <-- master
非常整潔，但它丟失了所有有用的提交資訊。
當更新一個分支，變基。這是因為更新合并對于理解為什么撰寫代碼沒有多大意義。他們只是掩蓋了真正的合并。
# Updating with `git merge master`
# This can look considerably worse if everyone is doing it.
E - F G - H <-- other people's features
/ \ / \
A - B ----- M ----- M <-- master
\ \ \
C - D - M - I - M - K - L <-- your feature
# Updating with `git rebase master`
E - F G - H <-- other people's features
/ \ / \
A - B ----- M ----- M
\
C - D - I - K - L <-- your feature
您的分支不是建立在新舊版本的 master 的組合上，而是每次提交都建立在最新版本的 master 上。這使得除錯和審查更簡單，最終合并的分支也更簡單。
# Merge after updating with `git merge master`
# Again, it can be considerably worse.
E - F G - H
/ \ / \
A - B ----- M ----- M --------- M <-- master
\ \ \ /
C - D - M - I - M - K - L
# Merge after updating with `git rebase master`
E - F G - H
/ \ / \
A - B ----- M ----- M ----------------- M <-- master
\ /
C - D - I - K - L
同樣，拉取只是提取加合并。拉取只是更新，因此改為使用 fetch 和 rebase--rebase或將其設定為默認值pull.rebase = merges。
uj5u.com熱心網友回復：
除了@Schwern 提到的技術細節 -
對于兩個不同的用例，合并和變基是兩個不同的事情。你不能比較他們兩個。
例如 -
當您執行 a 時git pull，您實際上是對您的分支執行 afetch和mergethe 。remotelocal
Rebase 在remote向前移動時使用，您的local分支也是如此，在此期間您無法直接將更改推送到remote. 您必須先做一個pull，不僅是，pull而且pull --rebase要按照它們從local和remote分支創建的順序應用每個提交。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/406878.html
標籤：