什么是gitflow？ 有什么优缺点？ git2. git的优点是3. GitFlow协同工作流程3.1 GitFlow的由来3.1 GitFlow中的分支角色们3.2 GitFlow的优点3.3 GitFlow的缺点总结
1 .什么是git
Git是一种分布式版本控制工具，分为远程仓库(位于云仓库和后端服务器上) (仓库，repository简称repo )和本地仓库。 本地和云仓库的维护机制相似，均使用类似树形结构的数据结构进行维护。 每当的文件内容更改时，它都会成为一个节点(blob节点)，每个commit都成为一个树节点，节点附带代码操作信息和节点类型。 详情请参阅传送门。
2 .千兆位优势千兆位是分布式的，具有本地分支管理功能，无需网络即可进行本地维护。 每个git更改都是一个节点，因此可以单独存储每个文件内容更改，并针对每个APP序列进行管理。 所有代码合并后也可以看到所有更改，但其他版本控制工具无法进行。 git非常快，因为它会在每次更改时生成完整的文件快照。 用空间换取时间。 由于git面临内存问题，它有自己的内存维护机制，例如删除不必要的节点和压缩软件包历史记录…git有非常多的命令，使用起来很灵活。 详细地说，传送门3. GitFlow协同工作流实现GitFlow不是一种技术，而是代码开发合并管理过程的思维模型或管理方法。 是大家开发的软约定。
3.1 GitFlow的由来为什么需要GitFlow这样的git管理流程？ 原因有以下几点
有稳定版本的代码分支，可以放心地在线发布。 在测试代码之前，也就是在代码达到预发布的状态时，在测试交付期间，程序员们可以继续下一版本的开发工作(每秒开发(_ -’) )。 有一个及时修复在线bug的分支。 在这个过程中，我不想把正在开发的代码提交给在线生产。 由于在这样的开发过程中面临的需求，GitFlow与国祚合作产生。 对应的点是
代码共享3.1 GitFlow的分支角色，用于管理防止不同环境中代码干扰的代码和环境完整性
主分支：用作发布环境的稳定版本代码分支。 您可以针对上述每次提交进行发布。 Feture分支：用于开发功能(需求)的功能分支，用于开发环境的Developer分支：开发分支。 Feture分支中的功能开发完成后，将Feture中的代码集成到Developer分支中，并在集成完成后删除该功能分支。 该分支支持集成测试环境。 准备发布前的发布前分支。 支持发布前的环境。 这个分支可以确保开发继续前进，以免为了发布而停滞不前。 在Release分支可释放后，必须将Release分支同时合并到Master、Developer分支中，以保持代码的一致性并删除Release分支。 Hotfix分支：用于修复在线错误的分支，每次修复在线代码中的错误时都在Hotfix中进行维护，完成后同时合并到Developer和Master中。 完成后删除分支。 以上是GitFlow所有角色的分支，从中可以看出以下内容。
大师和Developer需要我们的长期维护，是我们开发的主要干线。 其中relesase和hotfix两个分支操作零碎，操作麻烦，过程中容易出错，代码不一致。 要完成此过程，需要编号工具或脚本。 这个过程很麻烦，但他几乎可以应用于所有的开发过程。 瀑布型、敏捷性(waterfall，agile ) 3.2 GitFlow的优点适应场景多，不影响开发进度的分支使用比较有序，保证了在线版本的稳定性) 3.3 GitFlow的短
由于分歧态度，会出现git log混乱的局面。 由于git-flow主要使用git merge --no-ff合并分支，在git-flow这样的多分支环境中整个项目的log非常混乱。
从整体情况来看，如果只有feature要合并到developer分支中，则可以使用-no-ff参数，而其他合并不使用-no-ff
*什么是*gitmerge----no-ff :
--no-ff是指强制关闭快速向前方式。 fast-forward方式是指在条件许可时，git直接将HEAD指针朝向合并分支的开头完成合并的方式。 “快速前进方式”，否则如果删除分支，分支信息将丢失。 在此过程中，commit git merge --squash用于压缩不必要的commit。 例如，你的feature在开发时写的commit很混乱，我们合并的时候不想带这些历史commit，所以用--squash合并。 此时，文件已经与合并后相同。为了“总结”，需要进行其他commit，以完成最终的集成。 总结----no-ff :不采用快速向前合并，保留分支的commit历史记录--- -挤压：挤压方式合并，将多个分支的commit历史记录压缩为一次，与Master和Developer
是没必要的，因为在很多场景下Master中的内容和Developer中的内容是差不多的。尤其矮小的水杯想回滚某些人的提交时，你就会发现这事似乎有点儿不好干了。而且在工作过程中，你会来来回回地切换工作的分支，有时候一不小心没有切换，就提交到了不正确的分支上，你还要回滚和重新提交，等等。 总结这么看下来GitFlow还是不错的，毕竟他的应用场景比较全面，确实解决了开发时分支混乱的问题，而且为我们提供了代码分支管理的策略和思维。但是它也并不是完美的。我感觉像这种分支管理的规范只是万千分支管理策略中的一种，我们完全可以自己去对它进行修改和调整找到适合自己团队的管理策略。在找寻自己策略时我们可以参考一下几点：
不同团队保持并行开发软件版本和代码的一致性环境和代码的一致性保证线上有个稳定的代码源结合DevOps为主的开发流程（这个才是根本，才是未来）下面提供其他的一些策略，有兴趣的小伙伴可以自行查阅：
6. GitHub Flow
7. GitLab Flow