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>
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
此外，还有一些其他建议：
- master 分支的每一次更新，都建议打 tag 添加标签，通常为对应版本号，便于管理
- feature分支、hotfix分支在归并后可以删除，避免分支过多管理杂乱
- 每次 pull 代码前，提交本地代码到本地库中，否则可能回出现归并代码堕落，导致代码丢失
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
