git merge

假设有两个分支：master 分支和 feature 分支，现在需要将 feature 分支合并到 master 分支。

git checkout master

git merge feature

在合并分支时，git 提供了不同的合并策略，用于处理不同的合并场景。

• Fast-forward

  如果源分支（feature）与目标分支（master）之间没有分叉，即 master 分支在上次同步之后没有新的提交，那么当执行 git merge feature 时，git 会直接将 master 分支的指针移动到feature 分支的最新提交上，而不会创建新的合并提交。

合并前：

进行合并：

合并后：

快速合并不生成单独的合并提示从而不会留下合并痕迹，所以可以使用 git merge --no-ff feature 强制 git 在合并时创建一个新的合并提交。

• --no-ff

  如果 master 分支与 feature 分支之间存在分叉，即 master 分支产生了新的提交 M，此时无法快速合并，会采用 no-ff 方式进行合并，创建一个新的合并提示。如果两个分支存在代码冲突，需要先解决冲突再合并。

  合并前：
  
  合并后：

这样，合并后的历史就不再是线性的，而是包含了一个明确的合并点。

git rebase

git rebase 用于将当前分支的更新重新应用到另一个分支的最新更新上，使得项目历史更加线性。

假设有两个分支：master 分支和 feature 分支。master 是主分支，feature 是从 master 分支的某个提交点拉出的功能分支。现在，master 分支上有了新的提交，我们想要在保持 feature 分支更改的同时，将这些更改重新应用到 master 分支的最新状态上。

变基前：

以 master 分支为基，对 feautre 分支进行变基：

意味着将 feature 分支上的所有提交按照顺序重新应用到 master 分支的最新提交上。这个操作会改变 feature 分支的提交历史，使其看起来像是直接在 master 分支的最新状态上进行的开发。

git checkout feature
git rebase master

可以简写为 git rebase master feature

在变基过程中，如果 git 发现 feature 分支上的某个提交与 master 分支上的某个提交存在冲突，它会暂停变基过程，并让你手动解决这些冲突。解决冲突后，你需要使用 git add 命令将解决冲突后的文件添加到暂存区，然后使用 git rebase --continue 命令继续变基操作。

变基后：

rebase 操作过程中，只有当前分支（feature）的操作历史会被改变，而基分支（master）的操作历史不会变化。