GIT merge 和 rebase

今天新拍了个自拍照，先来炫耀一下，给各位大佬养养眼，接下来好认真的学习知识啊 😁

忽然想起了这个知识仍是由于最近刚学会使用sourTree，哈哈哈，不要嘲笑我，我以前只用git命令，学了这个才知道不打命令是多么的好，🤡，因此忽然来回顾了一下这个问题老生常谈可是怕本身忘记了，仍是记录一下，merge和rebase (￣▽￣)

1.git merge

我的以为这个图仍是挺有表明性的，主分支develop，在这个分支上我切出了本身的分支，就叫feature吧，简单来理解，就是本身在本身的feateure上提交了一些东西，这个时候，你的队友在主分支上也提交了一些东西，这个时候就会出现两个commit，主分支会新有一个commit来把子分支上的两个commit合并。这时候提交的形状就不是一条直线。

git rebase

rebase会把你当前分支的 commit 放到公共分支的最后面,因此叫变基。就好像你从公共分支又从新拉出来这个分支同样。你如今从主分支master拉一个feature分支出来，主分支又提交，当你开发完commit时，就会就会把你当前的几个 commit，放到那我的 commit 的后面。

变基/衍合，rebase，对指定的base自己并无什么影响；只是重写base以后的commit历史。

merge V.S. rebase

何时用merge；基于上述不一样的merge行为（fast-forward，--no-ff，squash），什么场景下用哪一种merge：

merge执行一个合并，这个合并应该反应业务层面的合并，而非技术行为。咱们但愿在当前分支上往前走，这样它就包含了其余分支的工做。

因此问题的关键是：这个“其余分支”是什么样的分支？这个“其余分支”须要在历史图谱中展现么？

本地的、临时的分支，使用它仅仅是为了使master保持clean。

1.若拉出本地分支后，master往前走了，此时在本地分支：

git rebase -i master
复制代码

将本地分支变基到最新的master节点（从新梳理本地历史提交信息好比合并成一个commit），好似本地分支就是在最新的master节点上作的开发工做，以保证合并到master后呈现线性增加。

2.在master上：

git merge (fast-forward)
复制代码

最终以一个或几个commit展示在master上。

知名分支，团队明肯定义的，多是用来追踪bug/feature。

永远不要用rebase，而是用

git merge --no-ff
复制代码

以保留清晰完整的历史图谱。