Git最佳实践-Git flow

news2024/10/5 16:30:36

Git分支管理背景

Git是当下最流行的版本管理系统，阮一峰在自己的博文中提到过：“如果你严肃对待编程，就必定会使用版本管理工具”。Git操作是基于分支的，当下环境衍生出多种优秀的分支管理策略，其目的就是要保证不同分支各司其职，避免多人协作过程中代码冲突、代码版本出现问题。在日常迭代过程中，每个公司都有一套自己的分支管理规范，但万变不离其宗，都有Vincent Driessen提出的Git flow方法的影子。

Git flow关键分支

基于Git flow方法协作提交代码时，一般是基于一下分支：

分支名称	分支说明	分支时效	环境
master	与线上环境运行代码版本一致，需保证最高稳定性	主分支	线上生产环境
develop	开发过程中成员操作分支（前后端对接调试阶段）	主分支	开发环境
feature	新功能分支，一般一个新功能对应一个分支，以避免后面一些不必要的代码冲突	临时分支
release	亦或者叫`bugfix`分支，修复测试环境Bug所用分支，建议一个Bug单独切一个分支，(测试阶段)	实施分支	测试环境/压测环境/预生产环境
hotfix	紧急修复线上BUG的时候使用的分支	临时分支

以下是Git flow流程图：

在这里插入图片描述

master与develop

这张图涉及内容较多，我们只需要关注两个分支，一个是master分支，另一个是develop分支，通过箭头可以看到，develop分支是基于master分支创建，在提交代码后，又重新回到了master分支，这里体现的是，在迭代开始前，需要基于线上代码最新版本合并到开发分支，作为团队成员开发的公共分支。在使用Git时，需要遵循一个原则：从哪里来，最后回到哪里去。

develop与feature

接下来我们需要关注的是feature分支与develop分支。在团队协作过程中，对于需求的开发，通常是采用一个成员负责一个功能点或者模块，那么就需要不同成员往develop分支提交代码，即需要从develop分支创建feature分支开发新功能，编码自测完成后，再从feature分支push（推送）到develop分支，这同样遵循了以上规则。

develop与release

在企业开发中，每次迭代往往定义一个版本号，release分支与之对应。随时间线推进，到达迭代开发中的提测阶段，则需要将开发的新代码从develop分支推送到release分支，而后发布代码(CI/CD)到测试环境供测试验证。

release与bugfix

当测试提出缺陷时，似乎我们需要排查一下自己代码中是否存在问题。如果是，那么我们需要基于测试环境的release分支代码版本做修改，此时，我建议基于release分支去创建一个bugfix分支用于修复代码中的问题。修复完毕后再将bugfix分支的代码推送到release分支，push完成后，将bugfix分支删除，确保一个bugfix分支只做一件事。

注意：在合并前需要确保release分支代码是最新版本，建议在push到其他分支前update一下分支到最新版本，因为不止你一个可怜人在修复Bug。

如果你所在的公司使用Git flow的标准流程。develop分支承担了两个“角色”：“写Bug”和“改Bug”。则同样可以从release分支更新最新代码后，将release分支代码merge(合并)到develop分支。再基于develop分支修改代码，push到develop，而后切换到release分支，更新到最新版本，merge develop分支到release分支即可。