高级程序员知识学习（工具集合操作——git）

Git merge 和rebase的区别

git rebase 和git merge 做的事其实是一样的。它们都被设计来将一个分支的更改并入另一个分支，只不过方式有些不同。

git merge

使用merge可以合并多个历史记录的流程。最简单的操作,如下图所示，仅有bugfix一个分支是从master分支分叉出来的。

合并 bugfix分支到master分支时，如果master分支的状态没有被更改过，那么这个合并是非常简单的。bugfix分支的历史记录包含master分支所有的历史记录，所以通过把master分支的位置移动到bugfix的最新分支上，Git 就会合并。这样的合并被称为fast-forward（快进）合并。

2.2 多人merge分支

master分支的历史记录有可能在bugfix分支分叉出去后被人有新的更新。这种情况下，要把master分支的修改内容和bugfix分支的修改内容汇合起来。

因此，合并两个修改会生成一个提交。这时，master分支的HEAD会移动到该提交上。

 执行合并时，如果设定了non fast-forward选项，即使在能够fast-forward合并的情况下也会生成新的提交并合并。

 执行non fast-forward后，分支会维持原状。那么要查明在这个分支里的操作就很容易了。

3.rebase：

跟merge的例子一样，如下图所示，bugfix分支是从master分支分叉出来的。

 如果使用rebase方法进行分支合并，会出现下图所显示的历史记录。现在我们来简单地讲解一下合并的流程吧。

 

首先，rebase bugfix分支到master分支, bugfix分支的历史记录会添加在master分支的后面。如图所示，历史记录成一条线，相当整洁。

这时移动提交X和Y有可能会发生冲突，所以需要修改各自的提交时发生冲突的部分。

rebase之后，master的HEAD位置不变。因此，要合并master分支和bugfix分支，即是将master的HEAD移动到bugfix的HEAD这里。 

3.总结

Merge和rebase都是合并历史记录，但是各自的特征不同。

merge：    保持修改内容的历史记录，但是历史记录会很复杂。
rebase：    历史记录简单，是在原有提交的基础上将差异内容反映进去。    因此，可能导致原本的提交内容无法正常运行。    您可以根据开发团队的需要分别使用merge和rebase。    例如，想简化历史记录。

在topic分支中更新merge分支的最新代码，请使用rebase。向merge分支导入topic分支的话，先使用rebase，再使用merge。

5.五类主要分支

• master主分支
• release分支
• develop分支
• feature分支
• hotfix分支

主分支

主分支有两种：master分支和develop分支

• master
  master分支只负责管理发布的状态。在提交时使用标签记录发布版本号。
• develop
  develop分支是针对发布的日常开发分支。刚才我们已经讲解过有合并分支的功用。

feature分支

这个分支是针对新功能的开发，在bug修正的时候从develop分支分叉出来的。基本上不需要共享特性分支的操作，所以不需要远端控制。完成开发后，把分支合并回develop分支后发布。

release分支

release分支是为release做准备的。通常会在分支名称的最前面加上release-。release前需要在这个分支进行最后的调整，而且为了下一版release开发用develop分支的上游分支。一般的开发是在develop分支上进行的，到了可以发布的状态时再创建release分支，为release做最后的bug修正。到了可以release的状态时，把release分支合并到master分支，并且在合并提交里添加release版本号的标签。要导入在release分支所作的修改，也要合并回develop分支。

hotfix分支

hotfix分支是在发布的产品需要紧急修正时，从master分支创建的分支。通常会在分支名称的最前面加上 hotfix-。例如，在develop分支上的开发还不完整时，需要紧急修改。这个时候在develop分支创建可以发布的版本要花许多的时间，所以最好选择从master分支直接创建分支进行修改，然后合并分支。修改时创建的hotfix分支要合并回develop分支。