Git Flow规范在工作中的使用流程

憧憬博客

发布于 2020-07-21 11:35:43

1.4K0

发布于 2020-07-21 11:35:43

我们在进行项目开发的时候，为了更好的管理项目、追溯项目历史，我们会采用代码管理。一般常用的有 git svn 等，但是项目的开发、测试、上线往往都是有很多工作，如果没有一个合适的管理规范那会导致项目出现一下不必要的麻烦。可能各个公司有不同的管理方式，本文博主分享一下我们一直沿用的 GIT 分支管理规范。

开发者一般都是开发完功能提交代码，这个时候由专人、或是版本管理员，将所有新功能集成起来，解决代码的冲突、然后准备发布新的版本。代码的合并总是让人担惊受怕，在版本的测试、发布也会伴随着不可预见的错误，在 2000 年的时候，Kent Beck 发布了具有开创性的著作《Extreme Programming Explained》，其中提出了「持续集成」的概念，即开发人员需要每几个小时或最多一天内进行编译然后合并代码到主分支最后再运行自动化测试。

用张图给大家描述一下

开发人员提交到仓库 -> 触发 CI Server（持续集成服务器）的相关功能。执行编译 -> 测试 -> 输出结果的流程，向开发人员反馈结果的 report

这种方式可以大大减少我们的成本，我们只要做好 git 分支的管理，每种类型的分支对应不同的操作即可很轻易使用持续集成

初试Git Flow

我们公司采用的就是选择 git flow 工作流程来方便持续集成。就像代码需要代码规范一样，分支管理同样需要一个清晰的流程和规范

上图描绘了 git flow 的分支管理流程，不懂没关系，我们再来白话一下。

Git Flow常用的分支

Master 分支

这个分支的代码是发布到生产环境的代码，这个分支只能从其他分支合并，不能在这个分支直接修改

Develop 分支

这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支

Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release

Release 分支

当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支

Hotfix 分支

当我们在Master发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release

Git flow工作流程

开始使用 Gitflow 之前，需要做一步一次性的初始化动作，就是从 master 分支上创建一个 develop 分支。自此，develop 分支将变成一个类似全能的分支，用来存放、测试所有的代码，同时也是主要是用来合并代码、集成功能的分支。

作为一个开发人员，在这是不允许直接提交代码到 develop 分支上的，更更更不允许直接提交到 master 分支

Master分支

所有在Master分支上的Commit应该Tag

当我们分配开发一个新功能的时候 feature/分支

你需要立即从 delevop 分支上创建一个 feature 分支。在 feature 分支的命名规则上，我们可以以 feature/功能名 来命名功能分支，当功能完成的时候，必须合并到 develop 分支，合并完成一般删除掉功能分支，提交的分支最好一天内合并到 develop 。

当我们开发完需要发布的时候 release/分支

当一期功能都开发完成都合并到 develop 后，我们基于 develop 分支创建一个 release/分支，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)

发布Release分支时，合并Release到Master和Develop，同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。