分支命名
master 分支
master 为主分支，也是用于部署出产环境的分支，需求确保master分支安稳性。master 分支一般由 release 以及 hotfix 分支兼并，任何时间都不能直接修正代码。
develop 分支
develop 为开发环境分支，始终保持最新完结以及bug修正后的代码，用于前后端联调。一般开发的新功用时，feature分支都是基于develop分支创立的。
feature 分支
开发新功用时，以develop为根底创立feature分支。
分支命名时以 feature/ 最初，后面能够加上开发的功用模块， 命名示例：feature/user_module、feature/cart_module
test分支
test为测验环境分支，外部用户无法访问，专门给测验人员运用，版别相对安稳。
release分支
release 为预上线分支（预发布分支），UAT测验阶段运用。一般由 test 或 hotfix 分支兼并，不主张直接在 release 分支上直接修正代码。
hotfix 分支
线上呈现紧迫问题时，需求及时修正，以master分支为基线，创立hotfix分支。修正完结后，需求兼并到 master 分支和 develop 分支。
分支命名以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 | 预上线分支，发布新版别 | UAT | 是 |
| hotfix | 紧迫修正分支，修正线上bug | 否 |
分支兼并流程标准
业界常见的两大主分支（master、develop）、三个辅佐分支（feature、release、hotfix）的生命周期：
以上生命周期仅作参考，不同开发团队或许有不同的标准，可自行灵活定义。
例如咱们团队在开发时，至少需求确保以下流程：
- develop 分支和 hotfix 分支，有必要从 master 分支检出
- 由 develop 分支兼并到 test 分支
- 功用测验无误后，由 test 分支兼并到 release 分支
- UAT测验通过后，由 release 分支兼并到 master分支
- 关于工作量小的功用开发（工时小于1天），能够直接在devolop 分支进行开发，不然由 develop 分支检出 feature 分支进行开发，开发完后兼并到develop 分支
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 代码前，提交本地代码到本地库中，不然或许回呈现兼并代码犯错，导致代码丢失
