IT评测·应用市场-qidao123.com

标题: git 分支管理规范 [打印本页]

作者: 罪恶克星 时间: 2024-9-17 20:46
标题: git 分支管理规范
分支命名

master 分支

        master 为主分支，也是用于部署生产环境的分支，需要确保master分支稳定性。master 分支一样平常由 release 以及 hotfix 分支合并，任何时间都不能直接修改代码。
develop 分支

        develop 为开发环境分支，始终保持最新完成以及bug修复后的代码，用于前后端联调。一样平常开发的新功能时，feature分支都是基于develop分支创建的。
feature 分支

        开发新功能时，以develop为基础创建feature分支。
        分支命名时以 feature/开头，背面可以加上开发的功能模块，命名示例：feature/user_module、feature/cart_module`
        主线开发分支：每个迭代只有一个主线开发分支，大部分功能在这个分支上开发
        命名规范： feature-${迭代发版日期}-${版本号}，比方 feature-20220710-1.3.0
        支线开发分支：用于主线开发分支并行的支线功能开发，由于此类功能开发周期长，与主线功能相对独立，为制止开发过程对主线分支造成影响，单独拉出支线分支
        命名规范：以主线开分支命称为前缀即可，比方 feature-20220710-1.3.0-springboot-upgrade，此中前缀feature-20220710-1.3.0 对应的主线开发分支名称
我们现在版本号：我们用产品Prd 定义的为准
test分支

        test为测试环境分支，外部用户无法访问，专门给测试职员利用，版本相对稳定。
release分支

        release 为预上线分支（预发布分支），UAT测试阶段利用。一样平常由 test 或 hotfix 分支合并，不发起直接在 release 分支上直接修改代码。
Uat 分支（同release）

        Uat 分支为交付验收分支，实在和release的作用一样
hotfix 分支

        线上出现告急问题时，需要及时修复，以master分支为基线，创建hotfix分支。修复完成后，需要合并到 master 分支和 develop 分支（test/uat cherry pick 合并同时保证问题再其他主线分支上修复）。
        分支命名以hotfix/ 开头的为修复分支，它的命名规则与 feature 分支雷同。

分支与环境对应关系

在体系开发过程中常用的环境：

DEV 环境（Development environment）：用于开发者调试利用
FAT环境（Feature Acceptance Test environment）：功能验收测试环境，用于测试环境下的软件测试者测试利用
UAT环境（User Acceptance Test environment）：用户验收测试环境，用于生产环境下的软件测试者测试利用
PRO 环境（Production environment）：生产环境

对应关系：
分支功能环境可访问合并职员master主分支，稳定版本PRO是运维职员管理develop开发分支，最新版本DEV是研发职员feature开发分支，实现新特性否研发职员test测试分支，功能测试FAT是测试职员管理release（cat）预上线分支，发布新版本UAT是测试职员、运维职员管理hotfix告急修复分支，修复线上bug否运维职员管理分支合并流程规范

业界常见的两大主分支（master、develop）、三个辅助分支（feature、release、hotfix）的生命周期：
以上生命周期仅作参考，不同开发团队大概有不同的规范，可自行机动定义。
比方我们团队在开发时，至少需要保证以下游程：

develop 分支和 hotfix 分支，必须从 master 分支检出
由 develop 分支合并到 test 分支
功能测试无误后，由 test 分支合并到uat 分支
UAT测试通过后，从master 拉 release 分支将uat 和新拉的 release中 , 线上验证没问题再合并到 master分支
对于工作量小的功能开发（工时小于1天），可以直接在devolop 分支进行开发，否则由 develop 分支检出 feature 分支进行开发，开发完后合并到develop 分支

具体操纵流程：
产品根据需求的优先级提前做好规划，确定每个迭代需要完成的需求，并规划好迭代的版本和评估大致的上线日期，基于产品规划的迭代，研发即可参与需求实现的设计和研发，在研发的过程中，Git需遵照如下游程

研发组长基于develop分支创建feature类的分支，并将该分支推送到远程，分支名: feature-版本号；示例: feature-3.7.0
研发同事将feature-3.7.0拉取到当地，然后在当地feature-3.7.0开发。
研发完成个人任务，并自测通过后，即可将【当地】feature-3.7.0的分支推送到【远程】feature-3.7.0 ，并将feature分支合并到develop分支，把develop部署到开发联调环境中进行联调
联调通过后，研发职员发起测试申请，转入测试阶段。测试职员把feature-3.7.0合并到test分支，然后test分支部署到测试环境进行测试
测试过程中发现的bug，研发职员仍在feature-3.7.0上修复，修复完再关照测试职员（每次可多修复一些，减少部署测试环境的次数），测试职员再通过合并到test分支的方式部署到测试环境，云云反复
测试竣过后，测试职员将test分支合并到uat分支，uat分支部署到UAT环境进行产品验收（这个可以按照具体要上uat的内容按需发布）
产品验收通过后，研发组长从master分支拉出相同版本号的release分支，示例: release-3.7.0，然后把UAT分支合并到release-3.7.0，由运维同事把release-3.7.0发到正式环境，开始线上验证
线上验证通过后，研发组长将release-3.7.0合并到master，打tag，并删除相应的主线feature分支
假如线上验证不通过，则运维直接把master分支部署到正式环境来实现回滚，相应的release-3.7.0分支删除，别的分支不要删除

分支版本号：
prd tapt. 蓝湖版本号保持一致

Git Commit Message规范

Git commit message规范指提交代码时编写的规范注释，编写良好的Commit messages可以达到3个重要的目标：

加速代码review的流程
帮助我们编写良好的版本发布日志
让之后的维护者了解代码里出现特定变化和feature被添加的缘故原由

Angular Git Commit Guidelines

业界应用的比较广泛的是Angular Git Commit Guidelines：

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

复制代码

type：提交范例
scope：可选项，本次 commit 波及的范围
subject：简明扼要的阐述下本次 commit 的主旨，在Angular Git Commit Guidelines中夸大了三点。利用祈使句，首字母不要大写，末了无需添加标点
body: 同样利用祈使句，在主体内容中我们需要把本次 commit 详细的描述一下，比云云次变更的动机
footer: 描述下与之关联的 issue 或 break change

浅易版

项目中实际可以采取浅易版规范：

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

复制代码

type规范

Angular Git Commit Guidelines中推荐的type范例如下：

feat: 新增功能
fix: 修复bug
docs: 仅文档更改
style: 不影响代码寄义的更改（空白、格式设置、缺失分号等）
refactor: 既不修复bug也不添加特性的代码更改
perf: 改进性能的代码更改
test: 添加缺少的测试或更正现有测试
chore: 对构建过程或辅助工具和库（如文档）的更改

除此之外，还有一些常用的范例：

delete：删除功能或文件
modify：修改功能
build：改变构建流程，新增依赖库、工具等（比方webpack、gulp、npm修改）
test：测试用例的新增、修改
ci：自动化流程配置修改
revert：回滚到上一个版本

单次提交注意事项

提交问题必须为同一种别
提交问题不要凌驾3个
提交的commit发现不符合规范，git commit --amend -m "新的提交信息"或 git reset --hard HEAD 重新提交一次

配置.gitignore文件

.gitignore是一份用于忽略不必提交的文件的列表，项目中可以根据实际需求统一.gitignore文件，减少不必要的文件提交和辩论，净化代码库环境。
通用文件示例：

HELP.md
target/
!.mvn/wrapper/maven-wrapper.jar
!**/src/main/**/target/
!**/src/test/**/target/
## STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
## IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr
## NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/
build/
!**/src/main/**/build/
!**/src/test/**/build/
## VS Code ###
.vscode/
# Log file
*.log
/logs*
# BlueJ files
*.ctxt
# Mobile Tools for Java (J2ME)
.mtj.tmp/
# Package Files #
*.jar
*.war
*.ear
*.zip
*.tar.gz
*.rar
*.cmd

复制代码

其他

此外，还有一些其他发起：

master 分支的每一次更新，都发起打 tag 添加标签，通常为对应版本号，便于管理
feature分支、hotfix分支在合并后可以删除，制止分支过多管理杂乱
每次 pull 代码前，提交当地代码到当地库中，否则大概回出现合并代码出错，导致代码丢失
每次提交说明清晰，“小步”前进

如何办理合并辩论

        feature（或hotix）分支合并到develop（或test、uat）辩论：
1、从develop分支checkout一个暂时分支tmp_develop_XXX(或tmp_test_XXX)，
2、然后把feature合并到tmp_develop_XXX(或tmp_test_XXX)，合并过程的代码辩论在tmp__develop_XXX(或tmp_test_XXX)上办理（注意，不是在feature上，也不是在develop（或test）上）
3、办理完辩论后，把tmp_develop_XXX(或tmp_test_XXX)合并到develop（或test）
4、删除tmp_develop_XXX(或tmp_test_XXX)
关于maven仓库的管理

        1、目前maven仓库deploy操纵暂时在develop/test/uat 分支进行，大家不要在别的分支上进行deploy操纵，相关的操纵规范正在美满
        2、将来计划，计划再弄一个开发专有maven私服，以后会有两套maven私服，以后的规范是以我们有两套私服为条件

常见问题

1、release分支发布到【正式环境】，在【正式环境】验证发现bug时，在哪个分支修复
        直接在release分支修复。修复完再发【正式环境】，再【线上验证】
2、线上验收通过后，支线开发分支是否可以删除
        假如支线开发分支已经合并到主线开发分支，则可以放心删除假如支线开发分支的代码没有合并的到主线开发分支，则说明此次线上验证并没有此分支的代码，需要找相应的开发职员问清晰后处理
3、开发职员可以在哪些分支上【提交】代码

feature分支release分支，只有release分支在线上验证发现bug时，才能在release分支提交代码hotfix分支其它一律禁止直接提交代码，

复制代码

4、开发职员可以向哪些分支【合并】代码

develop分支，主线featrue分支，

复制代码

5、任何情况下，绝对禁止develop合并到别的任何分支（当然，有的工程仍没有完成规范改造，改造过程中暂不用考虑此条）

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)