gitflow 是什么，有哪些优缺点？

1. 什么是git

Git是一个分布式的版本管理工具，它分为远程仓库（云端仓库，存在后端服务器中）（仓库：repository简写repo：）和本地仓库。本地和云端的仓库的维护机制是类似的，它们都是使用一个类似一个树形结构的数据结构来维护的。每次的文件内容的改变都是一个节点(blob节点)，每个commit都是一个tree节点，节点中附带代码的操作信息和节点类型。详见：传送门。

2. git的优点

1. git 是分布式的，有本地分支管理功能，所以，就算没有网络也可以进行本地的维护。
2. git的每个变动都是一个节点因此，每次的文件内容的变动都可以单独保存并且可以逐个的进行应用管理。在所有代码合并后也可以看到所有变更内容，而其他的版本管理工具则不可以。
3. 由于git每次的变更都会生成一个完整的文件快照，所以它非常快。用空间来换取时间。
4. 由于git会面临内存问题，它有自己的内存维护机制比如：删掉无用的节点，压缩打包历史记录等…
5. git有非常多的命令，可以灵活的使用。详见：传送门

3. GitFlow 协同工作流

其实GitFlow并非什么技术，而是一种代码开发合并管理流程的思维模式或者是管理方法。大家一起开发的一种软约定。

3.1 GitFlow的由来

我们为什么需要GitFlow这种git管理流程？原因有以下几点

1. 有一个稳定版本的代码分支，可以安心的用在线上发布。
2. 在代码提测前或者说是代码达到预发状态时，在测试交付的过程中程序员们还可以继续进行下一个版本的开发工作（挤出每一秒去开发-_-’’）。
3. 有个一个分支可以让我们及时的对线上的bug进行修复，这个过程中我们不希望将正在开发中的代码提交到线上生产中去。

由于上述开发过程中面临的需求，GitFlow协同国祚流应运而生。对应的点就是

1. 代码共享
2. 不同环境下代码互不干扰
3. 管理好代码与环境的一致性

3.1 GitFlow中分支角色们

1. Master 分支： 稳定版本代码分支，用作发布环境，上面的每次提交都是可以发布的。
2. Feture 分支： 功能分支，用于开发功能（需求），用于开发环境
3. Developer 分支: 开发分支， 一旦Feture分支内功能开发完成就将Feture中的代码合并到Developer分支中，合并完成后，删除该功能分支。这个分支对应的是集成测试环境。
4. Release 分支：预发分支，做发布前的准备工作，对应的是预发环境。这个分支可以确保们开发继续向前，不会因为要发布不而被停滞住。一旦Release分支达到了可发布的状态，我们需要把Release分支同时向Master，Developer分支上合并，保持代码的一致性，然后把Release分支删除。
5. Hotfix 分支： 线上bug修缮用的分支，每次修改线上代码的bug时都要用hotfix来维护，完成后向Developer和Master同时合并。完成后删除分支。

以上就是GitFlow中所有角色分支，从中我们可以看到以下几点：

1. Master和Developer需要我们长期维护，也是我们开发的主干线。
2. 其中relesase和hotfix两个分支的操作会很零碎，操作起来会比较麻烦，在这个过程中很容易产生失误，导致代码不一致。所以我们需要一个号的工具或者脚本来完成此步骤。
3. 这个套流程虽然麻烦，但是他可以应用到几乎所有的开发流程中：瀑布型，敏捷性（waterfall，agile）

3.2 GitFlow的优点

1. 适应场景多
2. 不影响开发进度
3. 分支使用相对有条理
4. 确保线上的版本稳定

3.3 GitFlow的缺点

当然GitFlow并不是完美的，这只是种管理思维，一下是他的一些缺点：

1. 因为分支态度，所以会出现git log混乱的局面：主要是因为git-flow使用git merge --no-ff来合并分支，在git-flow这种多分支的环境下会让整个项目的log变的非常混乱。

对于整个中情况我们可以：只有feature合并到developer分支时， 使用-no-ff参数，其他的合并都不使用–no-ff
** 什么是 git merge --no-ff：

	--no-ff指的是强行关闭fast-forward方式。
	fast-forward方式就是当条件允许的时候，git直接把HEAD指针指向合并分支的头，完成合并。属于“快进方式”，
	不这种情况如果删除分支，则会丢失分支信息。因为在这个过程中没有创建commit
	  
	git merge --squash 是用来把一些不必要commit进行压缩，比如说，你的feature在开发的时候写的commit很乱，
	那么我们合并的时候不希望把这些历史commit带过来，于是使用--squash进行合并，此时文件已经同合并后一样了,
	但不移动HEAD，不提交。需要进行一次额外的commit来“总结”一下，然后完成最终的合并。
	
	总结：
	--no-ff：不使用fast-forward方式合并，保留分支的commit历史
	--squash：使用squash方式合并，把多次分支commit历史压缩为一次

2. 同时维护Master和Developer两个分支很多时候是没必要的，因为在很多场景下Master中的内容和Developer中的内容是差不多的。尤其当你想回滚某些人的提交时，你就会发现这事似乎有点儿不好干了。而且在工作过程中，你会来来回回地切换工作的分支，有时候一不小心没有切换，就提交到了不正确的分支上，你还要回滚和重新提交，等等。

总结

这么看下来GitFlow还是不错的，毕竟他的应用场景比较全面，确实解决了开发时分支混乱的问题，而且为我们提供了代码分支管理的策略和思维。但是它也并不是完美的。我感觉像这种分支管理的规范只是万千分支管理策略中的一种，我们完全可以自己去对它进行修改和调整找到适合自己团队的管理策略。在找寻自己策略时我们可以参考一下几点：

1. 不同团队保持并行开发
2. 软件版本和代码的一致性
3. 环境和代码的一致性
4. 保证线上有个稳定的代码源
5. 结合DevOps为主的开发流程（这个才是根本，才是未来）

下面提供其他的一些策略，有兴趣的小伙伴可以自行查阅：
6. GitHub Flow
7. GitLab Flow