[历史归档]本文原发布于 cstriker1407.info 个人博客内容为历史存档仅供参考。发布时间2018-11-06 标题【转】git flow的使用分类编程 标签gitGit Flow工作流简单介绍简介工作原理用于功能开发的分支用于发布的分支用于维护的分支本文转自《 https://www.cnblogs.com/lcngu/p/5770288.html 》简介Gitflow工作流程围绕项目发布定义了严格的分支模型。尽管它比Feature Branch Workflow更复杂一些但它也为管理更大规模的项目提供了坚实的框架。与Feature Branch Workflow比起来Gitflow流程并没有增加任何新的概念或命令。其特色在于它为不同的分支分配了非常明确的角色并且定义了使用场景和用法。除了用于功能开发的分支它还使用独立的分支进行发布前的准备、记录以及后期维护。当然你还是能充分利用Feature Branch Workflow的好处拉拽请求Pull Request、隔离的试验以及更高效率的合作。工作原理流程仍然使用一个中央代码仓库它是所有开发者的信息交流中心。跟其他的工作流程一样开发者在本地完成开发然后再将分支代码推送到中央仓库。唯一不同的是项目中分支的结构。用于记录历史的分支Gitflow使用两个分支来记录项目开发的历史而不是使用单一的master分支。在Gitflow流程中master只是用于保存官方的发布历史而develop分支才是用于集成各种功能开发的分支。使用版本号为master上的所有提交打标签tag也很方便。事实上Gitflow流程就是围绕这两个特点鲜明的分支展开的。用于功能开发的分支每一个新功能的开发都应该各自使用独立的分支。为了备份或便于团队之间的合作这种分支也可以被推送到中央仓库。但是在创建新的功能开发分支时父分支应该选择develop而不是master。当功能开发完成时改动的代码应该被合并merge到develop分支。功能开发永远不应该直接牵扯到master。用于发布的分支一旦develop分支积聚了足够多的新功能或者预定的发布日期临近了你可以基于develop分支建立一个用于产品发布的分支。这个分支的创建意味着一个发布周期的开始也意味着本次发布不会再增加新的功能——在这个分支上只能修复bug做一些文档工作或者跟发布相关的任务。在一切准备就绪的时候这个分支会被合并入master并且用版本号打上标签。另外发布分支上的改动还应该合并入develop分支——在发布周期内develop分支仍然在被使用一些开发者会把其他功能集成到develop分支。使用专门的一个分支来为发布做准备的好处是在一个团队忙于当前的发布的同时另一个团队可以继续为接下来的一次发布开发新功能。用于维护的分支发布后的维护工作或者紧急问题的快速修复也需要使用一个独立的分支。这是唯一一种可以直接基于master创建的分支。一旦问题被修复了所做的改动应该被合并入master和develop分支或者用于当前发布的分支。在这之后master上还要使用更新的版本号打好标签。