突然想起了这个知识还是因为最近刚学会使用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
以保留清晰完整的历史图谱。
