除了@Schwern提到的技术细节之外-
对于两个不同的用例，合并和变基是两件不同的事情。你不能把两者都比较。
例如-
当你做一个git pull，你实际上做了一个fetch和merge的remote到你的local分支。
当remote向前移动时使用变基，你的local分支也是如此，在此期间你不能直接将你的更改推送到remote。你必须首先执行pull，不仅仅是pull，而是pull --rebase，以按照从local和remote分支创建的顺序应用每个提交。

***tl;dr***合并功能分支，重定基更新。

如果你要合并一个特性分支，那就合并。实际上，使用--no-ff强制合并（无快进）。这会给历史留下一个“特性气泡”，显示哪些提交被分组在一个分支中。你可以用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

类似地，pull只是一个fetch加上一个merge。pull只是更新，所以用--rebase来执行fetch和rebase，或者用pull.rebase = merges将其设置为默认值。