转载者总结了下原文的关键句，补充了几个相关链接，得到本文。

Git整合分支的两种方法

1、合并（git merge）

可以先看这篇文章先理解下Git的合并：Git：合并分支----git merge命令应用的三种情景_Samven_7的博客-CSDN博客
按照上图，这里是非快进的合并。
整合分支最容易的方法是 merge 命令。 它会把两个分支的最新快照（C3 和 C4）以及二者最近的共同祖先（C2）进行三方合并，合并的结果是生成一个新的快照（并提交）。

命令：

# 合并指定分支到当前分支
$ git merge <branch>

2、变基（git rebase）

其实，还有一种方法：你可以提取在 C4 中引入的补丁和修改，然后在 C3 的基础上应用一次。 在 Git 中，这种操作就叫做 变基（rebase）。 你可以使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

命令：

# 将主题分支<topicbranch>变基到目标分支<basebranch>上。
# 即提取在<topicbranch>上的补丁和修改，然后在<basebranch>的基础上应用一次。
$ git rebase <basebranch> <topicbranch>
或者
$ git switch <topicbranch>
$ git rebase <basebranch>

用例子理解 合并(git merge)与变基(git rebase)的区别

合并（git merge）

$ git switch master
$ git merge experiment# 没有冲突时不需要下方的命令。有冲突时，就修改冲突文件，再add然后commit该文件，如下：
$ git add readme.txt 
$ git commit -m "conflict fixed"

执行完上方的命令，达到下图效果：

此时可以删除dev分支：

$ git branch -d dev

---

变基（git rebase）

1、执行变基命令

# 提取在 experiment分支 中引入的补丁和修改，然后在 master分支 的基础上应用一次。
$ git rebase master experiment	
或者
$ git switch experiment
$ git rebase master

GitHub 解决 Git 变基后的合并冲突_w3cschool

变基的原理是首先找到这两个分支（即当前分支 experiment、变基操作的目标基底分支 master） 的最近共同祖先 C2，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件， 然后将当前分支指向目标基底 C3, 最后以此将之前另存为临时文件的修改依序应用。

执行完上方的命令，达到下图效果：

2、“快进”(无冲突)的合并

$ git switch master
$ git merge experiment

执行完上方的命令，达到下图效果：

3、此时可以删除dev分支：

$ git branch -d dev

要用变基得遵守一条准则：如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。
也就是说，只对尚未推送或分享给别人的本地修改执行变基操作清理历史， 从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式（变基 、 合并）带来的便利。

总结

这两种整合方法的最终结果没有任何区别，但是变基使得提交历史更加整洁。 你在查看一个经过变基的分支的历史记录时会发现，尽管实际的开发工作是并行的， 但它们看上去就像是串行的一样，提交历史是一条直线没有分叉。

一般我们这样做的目的是为了确保在向远程分支推送时能保持提交历史的整洁——例如向某个其他人维护的项目贡献代码时。 在这种情况下，你首先在自己的分支里进行开发，当开发完成时你需要先将你的代码变基到 origin/master 上，然后再向主项目提交修改。 这样的话，该项目的维护者就不再需要进行整合工作，只需要快进合并便可。

请注意，无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。

参考

转载自：Git - 变基

上文的两个链接：
Git：合并分支----git merge命令应用的三种情景_Samven_7的博客-CSDN博客
GitHub 解决 Git 变基后的合并冲突_w3cschool