Commit 9d0430ff authored by 郑伟's avatar 郑伟

根据睿涛的建议修改了部分流程

parent bce0272b
...@@ -38,7 +38,8 @@ dev分支是给客户端联调用的开发版本, 这个分支的代码是可以 ...@@ -38,7 +38,8 @@ dev分支是给客户端联调用的开发版本, 这个分支的代码是可以
用于开发新功能时所使用的feature分支; 用于开发新功能时所使用的feature分支;
用于辅助版本发布的release分支; 用于辅助版本发布的release分支;
用于修正生产代码中的缺陷的hotfix分支。 用于修正生产代码中的缺陷的hotfix分支;
用于工程师自己的独立分支需求的个人分支;
以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说,这些分支与Git其他分支并没有什么区别,但通过命名,我们定义了使用这些分支的方法。 以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说,这些分支与Git其他分支并没有什么区别,但通过命名,我们定义了使用这些分支的方法。
...@@ -55,26 +56,13 @@ feature分支通常是在开发一项新的软件功能的时候使用,这个 ...@@ -55,26 +56,13 @@ feature分支通常是在开发一项新的软件功能的时候使用,这个
一般而言,feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。 一般而言,feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。
### release分支
使用规范:
可以从pre分支派生
必须合并回pre分支和master分支
分支命名惯例:release/*
release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息(版本号、发布时间、编译时间等等)。通过在release分支上进行这些工作可以让pre分支空闲出来以接受新的feature分支上的代码提交,进入新的软件开发迭代周期。
当pre分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能,并且已通过所有测试时,我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内(避免由此引入一些不可控的系统缺陷)。
成功的派生了release分支,并被赋予版本号之后,pre分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。
### hotfix分支 ### hotfix分支
使用规范: 使用规范:
可以从master分支派生 可以从master分支派生
必须合并回master分支和pre分支 必须合并回master分支,pre分支,dev分支
分支命名惯例:hotfix/* 分支命名惯例:hotfix/*
除了是计划外创建的以外,hotfix分支与release分支十分相似:都可以产生一个新的可供在生产环境部署的软件版本。 除了是计划外创建的以外,hotfix分支与release分支十分相似:都可以产生一个新的可供在生产环境部署的软件版本。
...@@ -82,3 +70,12 @@ release分支是为发布新的产品版本而设计的。在这个分支上的 ...@@ -82,3 +70,12 @@ release分支是为发布新的产品版本而设计的。在这个分支上的
这样做的显而易见的好处是不会打断正在进行的pre分支的开发工作,能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。 这样做的显而易见的好处是不会打断正在进行的pre分支的开发工作,能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。
### 个人分支
使用范围
工程师自用
通过pull request merge到dev分支
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment