git docs : https://docs.github.com/cn
每次在合并分支代码，都不知道是该用git merge 还是rebase, 非常抓瞎，分不清它们的区别，这次就来搞清楚，再也不迷茫~

1. merge 和 rebase 的作用

• git merge 命令用于合并指定分支到当前分支
  * 当前分支master, 将dev 分支合并到当前分支： git merge dev 或者 git merge dev master , 合并后master 和dev 分支都指向最新的commit,

• git rebase 命令用于合并合并指定分支到当前分支

• merge 是一个安全的操作，不会改变历史的分支树

2. 场景

有mater 和 feature 分支如下：

git merge

执行命令：

git checkout feature
git merge master
以上等价于： git merge master feature

将master上的提交合并到feature 上，此时，在feature 上回自动产生一个新的commit（merge commit），如下：

git rebase

执行如下命令：

git checkout feature
git rebase master

下面来一个更形象的图：

image.png

3. merge 和 rebase 的相同点 和不同点

相同点

• 都是用于将一个分支的更改并入另一个分支，只不过方式不同

不同点

• 合并方式

  • merge master 分支的修改到 feature 分支上，会在feature 分支上产生一个新的commit 为 （merge commit）
  • rebase 的本质是变基，它会修改历史的分支树，如果将 master 分支合并到 feature 上，就会把 master上的提交全部移动到 feature 分支的顶部，然后将它们的分支树变成同一条直线
  • 如果rebase 过程中，想中途退出， 恢复rebase 前的代码， 可以用：git rebase --abort

• 冲突

  • rebase： 使用rebase 的冲突是一个一个解决，如果 有是个冲突，先解决第一个，然后使用命令 git add -u , git rebase --continue , 继续后才会出现第二个冲突，直到所有的冲突都解决完
  • merge ： 所有的冲突是全部显示出来

4. merge 和rebase 的优缺点

• 优点
  • merge 记录了真实的commit 情况，包括每个分支的详情
  • merge 全部冲突一次性解决
  • 变基： rebase 合并commit 历史，得到整洁的分支树
• 缺点
• merge 每次会产生一个新的commit ，污染分支
• merge 时会看到分支比较繁杂
• rebase 合并后代码出现问题，不容易定位，因为rewrite 了 history
• rebase 解决冲突要一次一次的解决

git rebase 场景分析：

5. merge 和 rebase 使用场景

Rebase 的黄金法则

never use it on the public branch （不要在公共分支上使用它）

• 一般情况，合并两个分支的代码，最好还是用merge 这种没有破坏性的合并方式
• 在git pull 的时候，会用--rebase
• 要合并的分支是自己的临时分支，用 git rebase 这种干净整洁的合并方式，将合并分支树变成一条直线

如果选择？

• 如果合并后想要一个干净的，没有merge commit 的线性历史树，选择 git rebase
• 如果想要保留完整的历史记录，避免重写commit history 的风险，选择 git merge

查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>
查看分支合并图: git log --graph pretty=online