Git中的merge和rebase

merge和rebase

git的merge和rebase都是用来合并分支的, 将一个分支的更改并入另一个分支。

git merge：将两个分支，合并结果提交为一个新提交，并且此新提交有2个parent。

比如现在的工程是这样的, 箭头是指向当次提交的父节点.

在此基础上执行merge, 会在 新分支上生成一个新的commit.C7有2个父节点

git rebase：会取消合并分支中的每个提交，并把他们临时存放，然后把当前分支更新到最新的origin分支，最后再把所有提交应用到分支上。

git rebase 可以把它理解成是“重新设置基线”，将你的当前分支重新设置开始点。这个时候才能知道你当前分支于你需要比较的分支之间的差异。
原理很简单：rebase需要基于一个分支来设置你当前的分支的基线，这基线就是当前分支的开始时间轴向后移动到最新的跟踪分支的最后面，这样你的当前分支就是最新的跟踪分支。

先把C5,C6生成一份拷贝, 然后在当前分支更新到最新的C4, 在把复制后的C5' 和C6'加到C4的后面, 旧的C5,C6会被删除

---

什么是分支

分支就是便于多人在同一项目中的协作开发。比方说：每个人开发不同的功能，在各自的分支开发过程中互不影响，完成后都提交到develop分支。极大的提高了开发的效率。

合并分支

每个人创建一个分支进行开发，当开发完成，需要合并到develop分支的时候，就需要用到合并的命令。

什么是冲突

合并的时候，有可能会产生冲突。

冲突的产生是因为在合并的时候，不同分支修改了相同的位置。所以在合并的时候git不知道那个到底是你想保留的，所以就提出疑问（冲突提醒）让你自己手动选择想要保留的内容，从而解决冲突。

merge和rebase的区别

1、采用merge和rebase后，git log的区别，rebase命令不会保留分支信息, 看不到分叉点：

2、处理冲突的方式：

• （一股脑）使用merge命令合并分支，解决完冲突，执行git add .和git commit -m'fix conflict'。这个时候会产生一个commit。
• （交互式）使用rebase命令合并分支，解决完冲突，执行git add .和git rebase --continue，不会产生额外的commit。这样的好处是，‘干净’，分支上不会有无意义的解决分支的commit；坏处，如果合并的分支中存在多个commit，需要重复处理多次冲突。

3、git pull和git pull --rebase区别

git pull = git fetch + git merge 。
git pull --rebase 多加了rebase就是以rebase的方式进行合并分支，相当于是git fetch + git rebase

---

如何选择合并分支的方式

合并的目的就是能够有效的管理代码, 当你是新手时, 无脑使用merge就行了, 当你觉得merge不好看, 时间线比较乱, 那认真的理解下rebase的作用, 然后在合适的情况下选择rebase或merge。

使用注意点:

• 不要在公共分支使用rebase,比如大家都在用的master, develop分支,最好使用merge, 方便看时间线和回滚.
• 自己的分支(只有自己在修改)或者本地和远端对应同一条分支,优先使用rebase,而不是merge,这样看起来舒服

rebase和merge对比

• rebase最大的好处是你的项目历史会非常整洁;  而merge会有各个分支合并, 看起来很多很乱
• rebase 导致最后的项目历史呈现出完美的线性——你可以从项目终点到起点浏览而不需要任何的 fork。这让你更容易使用 git log、git bisect 和 gitk 来查看项目历史
• 安全性，如果你违反了 rebase 黄金法则，重写项目历史可能会给你的协作工作流带来灾难性的影响; 而merge可以很轻松的找到并回滚到历史版本
• 可跟踪性，rebase 不会有合并提交中附带的信息——你看不到 feature 分支中并入了上游的哪些更改; merge可以很容易的看出来.