【GitFlow】GIT 工作流（GitFlow-如何使用Git的约定）

目录

什么是git-flow

简单概括：

详细描述：

工具推荐

---

什么是git-flow

 

是关于如何使用Git的约定；

不仅代码要有规范，代码的管理也要有规范的流程，所有目前很多工程师都在用gitflow方案。

 

简单概括：

master 生产主分支 , 产品的功能全部实现后 , 最终在此对外发布。

develop 主开发分支 , 基于master分支克隆。

feature 功能开发分支 , 基于develop分支克隆 , 主要用于新需求新功能的开发。

release 测试分支 , 基于feature分支合并到develop之后 , 从develop分支克隆。

hotfix 补丁分支 , 基于master分支克隆 , 主要用于对线上的版本进行BUG修复。

 

详细描述：

 

历史分支【master分支】需要遵循一个基本原则，所有在master分支上的commit应该tag。

 

 

相对使用仅有的一个master分支，Gitflow工作流使用2个分支来记录项目的历史。 master分支存储了正式发布的历史，而develop分支作为功能的集成分支。 这样也方便master分支上的所有提交分配一个版本号。

 

功能分支【feature分支】做完后，必须合并回develop分支, 合并完分支后一般会删点这个feature分支，但是也可以保留。

 

每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。 但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。 当新功能完成时，合并回develop分支。 新功能提交应该从不直接与master分支交互。 从各种含义和目的上来看，功能分支加上develop分支就是功能分支工作流的用法。但Gitflow工作流没有在这里止步。

 

发布分支【release分支】基于develop分支创建，打完release分支后，我们可以在这个release分支上测试，修改bug等。发布release分支时，合并release到master和develop， 同时在master分支上打个tag记住release版本号。

 

 

一旦develop分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从develop分支上checkout一个发布分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上—— 这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了， 发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。

使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段。

 

维护分支【hotfix分支】基于master分支创建，开发完后需要合并回master和develop分支，同时在master上打一个tag。

 

 

维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁， 这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和dev elop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

为Bug修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。 你可以把维护分支想成是一个直接在master分支上处理的临时发布。

 

工具推荐

 

Tower是mac上个人认为比较好用的git管理工具，图形操作其最重要是能够提升工作效率；

Tower支持git-flow，开箱就使用很方便；

→ settings → git-flow，出现配置弹框

 

 

 

总结：

今天了解了gitflow的代码管理流程，但我们的情况有点不一样，我觉得release环节应该可以不做，我们的测试环境是需要将研发完成的代码推到远程仓库分支，develop就能满足了；还有个问题：我们前后端调试，需要针对不同的功能切换不同的feature分支很麻烦，明天再问问别的或者刷刷帖子有没有更好的解决办法。

 

作者：ISIS卡拉肖克
链接：https://www.jianshu.com/p/f602da4484cf
作者：古碑先生
链接：https://www.jianshu.com/p/1ee9fe729c11