master 为主分支，也是用于部署生产环境的分支，需要确保master分支稳定性。master 分支一般由 release 以及 hotfix 分支合并，任何时间都不能直接修改代码。
develop 为开发环境分支，始终保持最新完成以及bug修复后的代码，用于前后端联调。一般开发的新功能时，feature分支都是基于develop分支创建的。
开发新功能时，以develop为基础创建feature分支。
分支命名时以 feature/ 开头，后面可以加上开发的功能模块， 命名示例：feature/user_module、feature/cart_module
test为测试环境分支，外部用户无法访问，专门给测试人员使用，版本相对稳定。
release 为预上线分支（预发布分支），UAT测试阶段使用。一般由 test 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支。修复完成后，需要合并到 master 分支和 develop 分支。
分支命名以hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似。
在系统开发过程中常用的环境：
对应关系：
|
分支 |
功能 |
环境 |
可访问 |
|
master |
主分支，稳定版本 |
PRO |
是 |
|
develop |
开发分支，最新版本 |
DEV |
是 |
|
feature |
开发分支，实现新特性 |
|
否 |
|
test |
测试分支，功能测试 |
FAT |
是 |
|
release |
预上线分支，发布新版本 |
UAT |
是 |
|
hotfix |
紧急修复分支，修复线上bug |
|
否 |
业界常见的两大主分支（master、develop）、三个辅助分支（feature、release、hotfix）的生命周期：
图片
以上生命周期仅作参考，不同开发团队可能有不同的规范，可自行灵活定义。
例如我们团队在开发时，至少需要保证以下流程：
Git commit message规范指提交代码时编写的规范注释，编写良好的Commit messages可以达到3个重要的目的：
业界应用的比较广泛的是Angular Git Commit Guidelines：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
项目中实际可以采用简易版规范：
<type>(<scope>):<subject>
Angular Git Commit Guidelines中推荐的type类型如下：
除此之外，还有一些常用的类型：
.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
此外，还有一些其他建议：
京公网安备 11010802035086号