代码版本管理规范

机械视角

发布于 2020-08-17 10:43:11

3K00

代码可运行

文章被收录于专栏：TensorbytesTensorbytes

运行总次数：0

代码可运行

代码版本管理规范

项目代码release包括三类：

大版本(x.0.0)
小版本(x.x.0)
补丁(x.x.x)

版本管理

git 流程模式有两种：一种是Git flow工作流，一种是Github flow工作流。

Git Flow 分支模型

@startuml
actor "person-repo"
participant "feature"
participant "develop"
participant "release-x.x"
participant "hotfix"
participant "master"
control "预发布环境"
control "生产环境"


master -> develop: checkout
develop -> "person-repo": pull
"person-repo" -> "person-repo": commit
"person-repo" -> develop: merge requests

develop -> feature: checkout（功能开发）
feature -> "person-repo": pull
"person-repo" -> "person-repo": commit
"person-repo" -> feature: merge requests
feature -> develop: merge

develop -> "release-x.x": checkout（版本发布）
"release-x.x" -> "person-repo": pull
"person-repo" -> "person-repo": fix bug
"person-repo" -> "release-x.x": merge requests
"release-x.x" --> "预发布环境": 测试
"release-x.x" -> master: merge
master --> "生产环境": 部署测试
"release-x.x" -> develop: merge

master -> "hotfix": checkout（线上bug紧急修复）
"hotfix" -> "person-repo": pull
"person-repo" -> "person-repo": fix bug
"person-repo" -> "hotfix": merge requests
"hotfix" -> master: merge
master --> "预发布环境": 测试
master --> "生产环境": 部署发布
"hotfix" -> develop: merge
@enduml

步骤

master分支不做代码提交，master为生产环境运行代码
开发主要在develop分支上进行提交
功能开发切换一个新的功能分支上，功能分支完成后需合并到develop分支
用release分支做版本发布，release用于预发布环境测试
release分支从开发分支切出来，完成后需要合并到master分支和develop分支
预发布环境测试无误后，release分支合并到master分支，发布到生产环境测试
生产环境测试完成后release分支可以删除
生产环境运行中紧急修复采用hotfix分支，hotfix分支从mater分支切出
hotfix分支修复后需合并会master分支和develop分支

功能开发

创建功能分支

# 从develop创建功能分支
$ git checkout -b myfeature develop

完成功能分支，合并develop，并推送到远程仓库

# 切换到develop分支
$ git checkout develop
# develop分支合并功能分支
$ git merge --no-ff myfeature
# 删除功能分支
$ git branch -d myfeature
# 推到远程仓库
$ git push origin develop

版本发布

版本发布前，创建版本分支

# 从develop分支切到版本发布分支
$ git checkout -b release-1.2 develop

完成版本测试后，合并到master分支上

# 切换到master
$ git checkout master
# master合并release分支
$ git merge --no-ff release-1.2
# 给master分支打tag
$ git tag -a 1.2

生产环境测试没有问题后，将release分支合并会develop分支，并删除release分支

# 切换到develop分支
$ git checkout develop
# develop分支合并release分支
$ git merge --no-ff release-1.2
# 删除release分支
$ git branch -d release-1.2

临时补丁

生产环境上发现bug，直接通过hotfix快速修复:

# 从master切出一条分支，紧急修复问题
$ git checkout -b hotfix-1.2 master

完成问题修复后，合并进master：

# 切到master分支
$ git checkout master
# master分支合并hotfix分支
$ git merge --no-ff hotfix-1.2
# 打上新tag
$ git tag -a 1.2
# 切换到develop分支

如果当前release分支还未删除，合并到release分支，再由release分支合并到develop分支:

$ git checkout release-1.2
# release-1.2合并hotfix分支
$ git merge --no-ff hotfix-1.2
# 删除hotfix分支
$ git branch -d hotfix-1.2
# 切换到develop分支
$ git checkout develop
# develop分支合并release分支
$ git merge --no-ff release-1.2

如果release分支已删除，则直接合并到develop分支：

# 切换到develop分支
$ git checkout develop
# develop分支合并release分支
$ git merge --no-ff hotfix-1.2
# 删除hotfix分支
$ git branch -d hotfix-1.2

原则

开发永远不直接提交到master分支，master保留用于发布到生产中的代码
尽量一个任务，一个功能分支
在合并到开发分支前，对每个merge requests测试
新功能只添加到develop分支

优缺点

优点：

流程清晰，覆盖面全，通过分支模型将工作流串通
git flow作为最早提出的分支模型，也是最广泛使用的分支模型，受众广泛
以master作为生产分支，面向单版本的线上产品迭代

缺点：

分支十分复杂，敏捷性较差
仅master分支上做持续集成，而大部分工具默认将master分支设为默认分支，因此经常面临分支切换，导致很繁琐
修补分支和发布分支设置繁琐，比如每次使用修补分支都需要同时合并到master和develop分支，但开发经常犯错误，比如忘记合并回develop分支

Github Flow 分支模型

面对git flow的繁琐，github flow分支模型仅具有功能分支和主分支，将所有内容合并到master分支中并进行部署，采用pull request方式进行代码合并，强调持续集成和连续交付。

优点：

流程十分简单，可以满足敏捷交付
不需要频繁切换分支，在自己的仓库进行开发，统一合并master
每次提交均需要测试

缺点：

对自动化测试要求较高，需要大量的单元测、端到端测试和集成测试
模型过于简单，对于部署、发版和集成上存在着大量问题

Gitlab Flow 分支模型

结合了git flow分支模型和github flow分支模型：

@startuml
actor "person-repo"
participant "master"
participant "release-x.x.x-alpha"
participant "release-x.x.x"
control "stage预发布环境"
control "pre-production"
control "生产环境"

master -> "person-repo": fork
"person-repo" -> "person-repo": commit
"person-repo" -> master: merge requests
master -> "stage预发布环境": 自动化测试CI
"stage预发布环境" -> master: 测试通过+code review

master -> "release-x.x.x-alpha": cherryPick
"release-x.x.x-alpha" -> "pre-production": 部署
"pre-production" -> "pre-production": 测试
"pre-production" --> "release-x.x.x-alpha": 测试不通过
"release-x.x.x-alpha" -> "person-repo": pull
"person-repo" -> "person-repo": fix bug
"person-repo" -> "release-x.x.x-alpha": merge requests
"release-x.x.x-alpha" -> "pre-production": 部署
"pre-production" -> "pre-production": 测试
"pre-production" --> "release-x.x.x-alpha": 测试通过

"release-x.x.x-alpha" -> "release-x.x.x": checkout -b
"release-x.x.x" -x "release-x.x.x-alpha": 删除分支alpha分支
"release-x.x.x" -> "生产环境": 部署
"生产环境" --> "生产环境": 测试
"生产环境" --> "release-x.x.x": 测试通过
"release-x.x.x" -> master: cherryPick
@enduml

需要一个staging环境和pre-production环境（两个生产环境镜像）
所有请求直接提交到master分支，每次提交都做持续集成和测试，主要是自动化测试
部署发布的时候，从master中摘取(cherry Pick)核心发布功能到”release-x.x.x-alpha”分支进行测试，并在其上进行修复
测试通过后，切换到”release-x.x.x”分支并删除”release-x.x.x-alpha”分支，将”release-x.x.x”分支发布到生产环境中进行测试
生产环境测试通过后，将”release-x.x.x”合并回master

要使用好cherry-pick，每个提交要清晰简洁