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

标题: Git代码管理规范 [打印本页]

作者: 知者何南 时间: 2024-12-11 17:48
标题: Git代码管理规范
1. 简介

git 分支分为集身分支、功能分支和修复分支，分别命名为 develop、feature 和 hotfix，均为单数。不可使用 features、future、hotfixes、hotfixs 等错误名称。
master（主分支，永远是可用的稳固版本，不能直接在该分支上开辟）
develop（开辟主分支，全部新功能以这个分支来创建自己的开辟分支，该分支只做只归并操纵，不能直接在该分支上开辟）
feature-xxx（功能开辟分支，在develop上创建分支，以自己开辟功能模块命名，功能测试正常后归并到develop分支）
feature-xxx-fix(功能bug修复分支，feature分支归并之后发现bug，在develop上创建分支修复，之后归并回develop分支。PS:feature分支在申请归并之后，未归并之前还是可以提交代码的，所以feature在归并之前还可以在原分支上继续修复bug)
hotfix-xxx（紧急bug修改分支，在master分支上创建，修复完成后归并到 master）
2. 分支命名

a. master 分支

master 为主分支，也是用于摆设生产情况的分支，必要确保master分支稳固性。master 分支一般由 release 以及 hotfix 分支归并，任何时间都不能直接修改代码。
b. develop 分支

develop 为开辟情况分支，始终保持最新完成以及bug修复后的代码，用于前后端联调。一般开辟的新功能时，feature分支都是基于develop分支创建的。
c. feature 分支

开辟新功能时，以develop为基础创建feature分支。
分支命名时以 feature/ 开头，背面可以加上开辟的功能模块，命名示例：feature/user_module、feature/cart_module
d. test分支

test为测试情况分支，外部用户无法访问，专门给测试人员使用，版本相对稳固。
e. release分支

release 为预上线分支（预发布分支），UAT测试阶段使用。一般由 test 或 hotfix 分支归并，不建议直接在 release 分支上直接修改代码。
f. hotfix 分支

线上出现紧急题目时，必要及时修复，以master分支为基线，创建hotfix分支。修复完成后，必要归并到 master 分支和 develop 分支。
分支命名以hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似。
3. 分支与情况

在系统开辟过程中常用的情况：
DEV 情况（Development environment）：用于开辟者调试使用
FAT情况（Feature Acceptance Test environment）：功能验收测试情况，用于测试情况下的软件测试者测试使用
UAT情况（User Acceptance Test environment）：用户验收测试情况，用于生产情况下的软件测试者测试使用
PRO 情况（Production environment）：生产情况
对应关系：

分支	功能	情况	可访问
master	主分支，稳固版本	PRO	是
develop	开辟分支，最新版本	DEV	是
feature	开辟分支，实现新特性		否
test	测试分支，功能测试	FAT	是
release	预上线分支，发布新版本	UAT	是
hotfix	紧急修复分支，修复线上bug		否

分支归并流程规范
业界常见的两大主分支（master、develop）、三个辅助分支（feature、release、hotfix）的生命周期：

以上生命周期仅作参考，差别开辟团队可能有差别的规范，可自行机动定义。
例如部门团队在开辟时，至少必要包管以下流程：
develop 分支和 hotfix 分支，必须从 master 分支检出
由 develop 分支归并到 test 分支
功能测试无误后，由 test 分支归并到 release 分支
UAT测试通过后，由 release 分支归并到 master分支
对于工作量小的功能开辟（工时小于1天），可以直接在devolop 分支进行开辟，否则由 develop 分支检出 feature 分支进行开辟，开辟完后归并到develop 分支
4. 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 重新提交一次
5. .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

复制代码

6. 其他

此外，还有一些其他建议：

master 分支的每一次更新，都建议打 tag 添加标签，通常为对应版本号，便于管理
feature分支、hotfix分支在归并后可以删除，避免分支过多管理杂乱
每次 pull 代码前，提交本地代码到本地库中，否则可能回出现归并代码堕落，导致代码丢失

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

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