git 第三种合并： rebase

一、fast-forward

所谓 fast-forward，就是我们新创建的分支 dev 上面，有着 master 分支的最新内容。

这样，我们就可以在 master 分支上执行 git merge dev进行合并，而不会有人任何冲突。

---

二、3 way merge

如果我们的 dev 分支没有 master 分支最新的修改，此时执行进行 merge 合并操作就可能存在 master 分支和 dev 分支修改同一个文件内容的情况，就可能存在冲突。

此时直接进行合并的话，可能需要解决冲突，并创建一次新的 commit。

---

三、rebase

如果我们希望把 “3 way merge” 变成 “fast-forward”的情况，应该怎么做呢？

首先需要满足前提：创建 dev 分支以后，master 分支的内容没有变过；也就是， dev 分支上拥有 master 分支的最新 commit（侧面也说明了创建 dev 分支后 master 没有改变。）

如下图所示的“3 way merge”，因为 merge 之前，master 分支的最新 commit 是图中的 2；而 dev 分支创建的时候，拥有的只是 master 分支图中的3。所以此时 dev 分支最新的 commit 图中的1所示，并没有 master 分支的最新 commit 图中的 2，此时就不是 “fast-forward”.

rebase 的目的就是：让 dev 分支拥有 master 分支最新的 commit，这样就可以 “fast-forward”。

如下图，dev 分支基于 master 分支的 commit 1创建，然后 master 分支最新提交是 commit 4. 此时 dev 分支的最新提交 commit 3，就没有 master 分支的最新提交 commit 4 的内容。

之后，我们在 dev 分支执行 git rebase master 之后， dev 分支的就有了 master 分支的最新提交 commit ，这样就满足“fast-forward”的条件了。

注意：由于 commit 的 哈希 SHA1值和文件的长度和文件的内容相关，所以合入 master 分支的最新 commit 之后，dev 分支的哈希 SHA1值都会改变。

---

四、rebase带来的问题

1. rebase 合入 master 分支的最新 commit ，可能存在 master 分支和 dev 分支的修改内容有冲突，这时候就需要我们去解决冲突。
2. 由于 dev 分支的 哈希 SHA1 值发生改变。如果在 rebase 之前，我们已经将 dev 分支的内容 push 到远程仓库了，由于 rebase 命令修改了 dev 分支的SHA1值，后面去 push 到远程仓库的时候就会报错（可以强制 push 来解决）。
3. 如果在 rebase 之前，已经将 dev 分支 push 到远程仓库了，而且其他开发者已经将我们的 dev 分支拉取到他个人的本地进行开发了。此时我们 rebase 并强制 push 到远程仓库，此时远程仓库的 dev 分支的 SHA1哈希值就和其他开发者本地的 SHA1值不一样了，会给其他开发者造成不好的影响（除非当前这个 dev 分支只有我们一个人在开发）。
4. 只能在 dev 分支上进行 rebase，不可以在 master 分支进行 rebase 操作，这样会导致所有引用 master 分支的开发者全都受到影响，十分严重。