Git 团队协作流程规范

前言

在使用Git的过程中如果没有清晰流程和规划，否则每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。

Git版本管理同样需要一个清晰的流程和规范。

Vincent Driessen 为了解决这个问题提出了 A Successful Git Branching Model

以下是基于Vincent Driessen提出的Git Flow 流程图 （非常清晰，图片上的英文可以翻译一下便于理解）

image

分支约定

主分支

image

主分支分为master分支和develop分支，是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中, 生命周期为常驻。

master 分支

• master分支存放的是随时可供在生产环境中部署的稳定版本代码

• master分支保存官方发布版本历史，release tag标识不同的发布版本

• 一个项目只能有一个master分支

• 仅在发布新的可供部署的代码时才更新master分支上的代码

• 每次更新master，都需对master添加指定格式的tag，用于发布或回滚

• master分支是保护分支，不可直接push到远程仓master分支

• master分支代码只能被release分支或hotfix分支合并

develop 分支

• develop分支是保存当前最新开发成果的分支

• 一个项目只能有一个develop分支

• develop分支衍生出各个feature分支

• develop分支是保护分支，不可直接push到远程仓库develop分支

• develop分支不能与master分支直接交互

辅助分支

image

辅助分支分为feature分支、release 分支、hotfix 分支，辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同，通常只会在有限的时间范围内存在

feature 分支

使用规范：

• 命名规则：feature/*

• develop分支的功能分支

• feature分支使用develop分支作为它们的父类分支

• 以功能为单位从develop拉一个feature分支

• 每个feature分支颗粒要尽量小，以利于快速迭代和避免冲突

• 当其中一个feature分支完成后，它会合并回develop分支

• 当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支

• feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里

• feature分支只与develop分支交互，不能与master分支直接交互

如有几个同事同时开发，需要分割成几个小功能，每个人都需要从develop中拉出一个feature分支，但是每个feature颗粒要尽量小，因为它需要我们能尽早merge回develop分支，否则冲突解决起来就没完没了。同时，当一个功能因为各种原因不开发了或者放弃了，这个分支直接废弃，不影响develop分支。

release 分支

使用规范：

• 命名规则：release/*，“*”以本次发布的版本号为标识

• release分支主要用来为发布新版的测试、修复做准备

• 当需要为发布新版做准备时，从develop衍生出一个release分支

• release分支可以从develop分支上指定commit派生出

• release分支测试通过后，合并到master分支并且给master标记一个版本号

• release分支一旦建立就将独立，不可再从其他分支pull代码

• 必须合并回develop分支和master分支

release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。

当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。

成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

hotfix 分支

使用规范：

• 命名规则：hotfix/*

• hotfix分支用来快速给已发布产品修复bug或微调功能

• 只能从master分支指定tag版本衍生出来

• 一旦完成修复bug，必须合并回master分支和develop分支

• master被合并后，应该被标记一个新的版本号

• hotfix分支一旦建立就将独立，不可再从其他分支pull代码

除了是计划外创建的以外，hotfix分支与release分支十分相似：都可以产生一个新的可供在生产环境部署的软件版本。

当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。

这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。

Git Flow 如何使用

• Master/Develop 分支

所有在Master分支上的Commit应该打上Tag，一般情况下Master不存在Commit，Devlop分支基于Master分支创建

image

• Feature 分支

Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，毕竟保留下来意义也不大。

image

• Release 分支

Release分支基于Develop分支创建，打完Release分支之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于Develop分支新建Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。

image

• Hotfix 分支

hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag。

image

使用规范

所有使用了本规范的项目，必须严格规范操作，否则不予以合并代码、提测、打包上线等后续操作

基本要求

• 所有commit必须有注释，内容必须简洁明了的描述本次commit涵盖了哪些内容。严禁注释内容过于简单或不能明确表达提交内容的！

• 合理控制提交内容的颗粒度，一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。

• 正确为每个项目设置Git提交用到的user.name和user.email信息，以公司邮箱为准，不可随意设置以影响无法正确识别。 查看当前项目配置信息的命令：git config -l

commit提交规范

<type>(<scope>): <subject>

type

commit 的类型：

• feat: 新功能、新特性

• fix: 修改 bug

• perf: 更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化）

• refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）

• docs: 文档修改

• style: 代码格式修改, 注意不是 css 修改（例如分号修改）

• test: 测试用例新增、修改

• build: 影响项目构建或依赖项修改

• revert: 恢复上一次提交

• ci: 持续集成相关文件修改

• chore: 其他修改（不在上述类型中的修改）

• release: 发布新版本

• workflow: 工作流相关文件修改

scope

commit 影响的范围, 比如: route, component, utils, build...

subject

commit 的概述

示例

fix

如果修复的这个BUG只影响当前修改的文件，可不加范围。如果影响的范围比较大，要加上范围描述。

例如这次 BUG 修复影响到全局，可以加个 global。如果影响的是某个目录或某个功能，可以加上该目录的路径，或者对应的功能名称。

// 示例1
fix(global):修复checkbox不能复选的问题
// 示例2 下面圆括号里的 common 为通用管理的名称
fix(common): 修复字体过小的BUG，将通用管理下所有页面的默认字体大小修改为 14px
// 示例3
fix: value.length -> values.length

版本号(tag)

• 版本号(tag)命名规则：主版本号.次版本号.修订号，如2.1.13。(遵循GitHub语义化版本命名规范)

• 版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码

• 对master标记tag意味着该tag能发布到生产环境

• 对master分支代码的每一次更新(合并)必须标记版本号

• 仅项目管理员有权限对master进行合并和标记版本号

项目权限

• Git权限分管理员、开发者、浏览者三种类型

• 浏览者只能浏览代码，无push、pull request等所有写权限

• 开发者拥有浏览、push非主分支、提交pull request工单权限

• 管理员拥有建立和管理Git项目、合并分支和代码、给master打tag版本号等权限

分支使用

• 每个Git项目固定含有上述所有分支类型。主分支master和develop是保护分支，只能进行合并请求，均不可直接提交代码。

• 功能需求或常规Bug修复，请从develop拉取feature分支；线上紧急问题修复，请从master拉去hotfix分支。

代码提交

• 一个提交就代表解决一个问题

• 大问题适当地分解为多个小问题，以便每次小型提交都更易于理解

• 提交前本地代码需要编译成功，并检查一下提交的代码 (这一步很重要，测试代码、简单的逻辑错误都可以被发现, 可以有效解决简单粗心的bug产生)

参考资料：

Git工作流与规范

Git Flow正确使用姿势

Git Commit提交规范