经历了好几个公司和开发团队，git 的使用流程依旧不清晰
看到网上已经太多 git 教程，不重复 git 的用法，这里重点是开发实战流程。
开发流程
Git 服务器上从开发分支产生出一个 feature-xxx 分支；
把 feature-xxx 分支 clone 到本地；
疯狂写代码；
同步服务器上 feature 分支（
pull&rebase）并解决冲突 + 本地测试，重复直至无更新 & 冲突；commit 更新，并
push到 服务器 feature 分支上；服务器触发 feature build，如果不成功，拒绝
merge请求，重复步骤 3 ～ 6，直至 feature 开发完成提交 merge request 到开发分支
主管 code review，检查 feature build 成功，则同意 merge request，feature 上的更新合并到开发分支上，触发 dev build，如不成功，通知主管，回到步骤 3
分支策略说明
分支策略可简单，可复杂（trunk-based，git flow，github flow 等等），因为和项目管理策略，测试策略，发布策略，等等相关，如生产环境需要支持多版本，多客户。策略没有绝对好坏，原则是维护尽量少的分支。策略和执行好坏有关，如网上有人建议或膜拜 Google 的 trunk-based 策略，而忘了自己软件项目的特点。每个人都有盲区，老大也未必靠谱：
主分支/master
主分支 ➡ 生产环境
主分支对应生产环境，一般不允许直接在主分支上做修改
开发分支/dev
开发分支 ➡ 开发集成测试环境
开发分支用于集成测试，以及用户测试，有条件的可以细化不同的测试环境，如 release，staging
feature 分支
feature分支 ➡ feature测试环境从开发分支上 fork 出 feature 分支：
所有的开发工作都在本地 feature 分支上进行 由于是团队协作，例如 Raj 也在开发同一 feature：
每个开发者都要做
pull和rebase的两个动作（下载同事的 commit 到本地）：
缺认无误后可以
merge回开发分支（经主管同意）
发布分支/release
开发分支 ➡ 测试环境经过一定阶段，从开发分支产生发布分支，测试成功可以
merge回主分支：
hotfix 分支
hotfix分支 ➡ hotfix测试环境可以考虑 hotfix 分支来修改生产环境出现的 bug：
- 从主分支产生 hotfix 分支；
- 开发
- 测试（hotfix 测试环境）
- merge 回 master 以及开发分支
hotfix 分支用来支持对多版本生产环境，但使环境和开发流程变得复杂，如果不是多版本，可以使用 feature 分支来修改 bug
Git 使用规范和检查
commit msg
目前主流的 commit 前缀包括以下部分：
build：表示构建，发布版本可用这个
ci：更新 CI/CD 等自动化配置
chore：杂项，其他更改
docs：更新文档
feat：常用，表示新增功能
fix：常用：表示修复 bug
perf：性能优化
refactor：重构
revert：代码回滚
style：样式更改
test：单元测试更改
加强工具：
> npm install -g commitizen cz-conventional-changelog
git hook
git hook 分为客户端 hook 和服务端 hook。
客户端 hook 主要有四个：
- pre-commit：提交信息前运行，可检查暂存区的代码
- prepare-commit-msg：不常用
- commit-msg：非常重要，检查提交信息就用这个钩子
- post-commit：提交完成后运行
服务端 hook 包括：
- pre-receive：非常重要，推送前的各种检查都在这
- post-receive：不常用
- update：不常用
大多数团队是在客户端做校验，所以可以用 commit-msg 钩子在客户端对 commit 信息做校验，社区有成熟的方案：husky + commitlint。