Git 命令 merge 合并概述与 分支开发工作流
目录
merge 合并概述
rebase VS merge
分支开发工作流
长期分支
特性分支
merge 合并概述
1、合并（merge）命令把不同的分支合并起来，可能从 master 分支中切出一个分支，然后进行开发完成需求，中间经过R3,R4,R5 的 commit 记录，最后开发完成需要合入 master 中，这便用到了 merge。
2、如果在 merge(合并)之后，出现了 conflict(冲突)，则需要针对冲突情况，手动解除冲突，引起冲突的主要是因为多个用户修改了同一文件的同一块区域。
rebase VS merge
1、假如有如下两个分支 test和master。
D---E test
/
A---B---C---F master2、在 master 执行 git merge test 后会得到如下结果：
D--------E
/ \
A---B---C---F----G test, master3、在 master 执行 git rebase test后得到如下结果：
A---B---D---E---C'---F' test, master4、可以看到 merge 操作会生成一个新的节点，之前的提交分开显示，rebase 操作不会生成新的节点，是将两个分支融合成一个线性的提交。
5、如果想要一个干净的没有 merge commit 的线性历史树，那么应该选择git rebase；如果想保留完整的历史记录，并且想要避免重写 commit history 的风险，则应该选择使用 git merge(常用方式)
分支开发工作流
长期分支
1、因为 git merge 使用简单的三方合并，所以就算在一段较长的时间内，反复把一个分支合并入另一个分支，也不是什么难事。 整个项目开发周期的不同阶段，可以同时拥有多个开放的分支，可以定期地把某些特性分支合并入其他分支中。
2、比如只在 master 分支上保留完全稳定的代码（可能仅仅是已经发布或即将发布的代码），他们还有一些名为 develop 或者 next 的平行分支，被用来做后续开发或者测试稳定性，这些分支不必保持绝对稳定，但是一旦达到稳定状态，它们就可以被合并入 master 分支了。
3、稳定分支的指针总是在提交历史中落后一大截，而前沿分支的指针往往比较靠前：
4、通常把他们想象成流水线（work silos），那些经过测试考验的提交会被遴选到更加稳定的流水线上去。
5、可以用这种方法维护不同层次的稳定性，这么做的目的是使你的分支具有不同级别的稳定性，当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中。 当然使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一个非常庞大或者复杂的项目中工作时。
特性分支
1、特性分支对任何规模的项目都适用，特性分支是一种短期分支，它被用来实现单一特性或其相关工作。因为在 Git 中一天之内多次创建、使用、合并、删除分支都很常见。
2、工作被分散到不同的流水线中，在不同的流水线中每个分支都仅与其目标特性相关，因此在做代码审查之类的工作的时候就能更加容易地看出你做了哪些改动。可以把做出的改动在特性分支中保留几分钟、几天甚至几个月，等它们成熟之后再合并，而不用在乎它们建立的顺序或工作进度。
3、考虑这样一个例子，你在 master 分支上工作到 C1，这时为了解决一个问题而新建 iss91 分支，在 iss91分支上工作到 C4，然而对于那个问题你又有了新的想法，于是你再新建一个 iss91v2 分支试图用另一种方法解决那个问题，接着你回到 master 分支工作了一会儿，你又冒出了一个不太确定的想法，你便在 C10的时候新建一个 dumbidea 分支，并在上面做些实验。 于是你的提交历史看起来像下面这个样子：
4、现在假设：你决定使用第二个方案 iss91v2 来解决那个问题，另外你将 dumbidea 分支拿给你的同事看过之后，结果发现这是个惊人之举。 这时你可以抛弃 iss91 分支（即丢弃 C5 和 C6 提交），然后把另外两个分支合并入主干分支。于是提交历史看起来像下面这个样子：
