Git使用规范

矫情吗；* 2022-12-03 08:30 140阅读 0赞

# Git使用规范 #

大家都比较清楚，互联网产品要能够快速响应市场变化，要面对频繁的需求变更，要用廉价的成本快速试错，这样才能不断的完善和优化产品。

Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。非常适合做互联网产品的代码版本管理。

一个团队如何如何使用git进行版本管理，如何使用git进行多人的代码写作？如何解决产品开发过程中的提出来的版本控制的问题？就是我要表达的意思。

团队如何进行版本管理呢？

## 第一，GitServer的选型和安装 ##

我选用了GitLab作为GitServer。GitLab是一个开源的版本管理系统，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释等，还有一个功能，它能够实现分支的在线合并申请，分支可以进行保护等权限的控制。

## 第二，版本号定义规范 ##

约定版本号规范，每个模块的版本号约定为三位<main>.<feature>.<hotfix>，根据大的基线设定<main>主要版本号，根据当前版本设定<feature>次版本号，<hotfix>默认为0，当有bug修改后才更新这个版本号。每次产品人员定义好产品功能后，每次变更<feature>版本号即可。

## 第三，创建固定分支 ##

每创建一个项目，分别创建dev、test、release、master四个固定分支。

dev分支用来研发人员进行自测和模块间联调使用的，用来部署到研发环境的，开发人员对该分支有pull和push权限。

test分支是测试人员进行测试的代码分支，是部署到测试环境的代码分支，研发人员联调完自测完成后，提交feature分支合并申请到test分支，由管理员负责代码review并进行代码合并，该分支是受保护分支，开发人员对该分支有pull权限。

release分支是在test分支测试完成后，由研发人员提交test分支合并申请到release分支，release代码分支是用来部署到预生产环境的，由管理员进行代码合并。

master分支是最终上线的代码分支，测试人员在预生产环境测试通过后，由研发人员提交release代码分支合并申请到master分支，master分支是要部署到生产环境的，master上线完成后打对应版本的tag标签。

## 第四，临时分支 ##

feature分支，每次定义产品一个完整的基线版本就生成一个feature\_\{版本号\}分支，上线完成后删除该分支，所有的人创建一个属于自己的分支，每个人自测完成后，发起自己分支合并到feature分支，然后将feature分支合并到dev分支。

hotfix分支，每次bug修复创建一个hotfix\_\{版本号\}分支，生产环境出现bug后，需要马上修改时，确定好版本号，从继承master分支创建hotfix分支。

## 第五，正常上线流程 ##

1）管理员创建固定的分支dev、test、release和master版本，根据产品人员确定的功能确定当前版本的版本号，并继承master分支创建feature分支。

2）每个研发人员拉取feature分支，并创建个人本地分支。