如果不是大项目/大团队，很多细节和步骤上就没有那么讲究。
看到网上已经太多 git 教程，不重复 git 的用法，这里重点是 feature 开发流程：
git 服务器 上从 主分支 fork 出一个 feature 分支（纯自用） ，因为开发都在这个分支 feature-XXXXX 上；
把 feature-XXXXX 分支 clone 到本地；
疯狂写代码；
更新（同步服务器上 feature 和主分支）并解决冲突 + 本地测试，重复直至无更新 & 冲突；
commit 更新，并 push 到服务器上
服务器触发 feature build（测试主分支+feature） ，如果不成功，重复步骤 3 ～ 6，直至 feature 完成
提交 merge request
主管 code review，检查 feature build 成功，则同意 merge request，feature 上的更新合并到主分支上，触发主分支 dev build，如不成功，通知主管，回到步骤 3
📝 说明：
- git 服务器可以是 gitlab，bitbucket，公司自用 git 一般要本地化和深度定制，github 不合适 ¹
- git 主分支由你的分支策略决定，可以是 master， dev， release 等 ²
- feature 分支和管理工具如 Jira 结合（通过 issue/ticket no XXXXX），便于项目管理，追踪和构建 ³
- CICD 服务器上构建各种开发 pipeline：feature build，dev build，release build 等 ⁴
- 所有的代码更新必须通过 feature 分支；合并到主分支的代码一定要保障 build 成功
- 只有主管有权限直接更新主分支，更新的内容限制在非代码信息，如版本号，项目描述等
- feature 分支可以在合并，或者主分支 release build 后删除，由你的分支策略决定
其中的一些细节如 commint 的格式化，合并用 merge 还是 rebase，等等，不展开讨论。
分支策略可简单，可复杂（trunk-based，git flow，github flow 等等），因为和项目管理策略，测试策略，发布策略，等等相关，如生产环境需要支持多版本，多客户。策略没有绝对好坏，原则是维护尽量少的（主）分支，策略和执行好坏有关，如网上有人建议或膜拜 Google 的 trunk-based 策略，而忘了自己软件项目的特点。每个人都有盲区，老大也未必靠谱：
整个项目的开发流程，除了最基础的 feature 开发外，还有环境构建流程，发布流程，部署流程，复杂程度同样取决项目。大型项目/软件要做到运维自动化、流畅化，真的有太多的工作 🥵。
develop -> (merge) -> dev-* dev-* -> (cherry-pick) -> develop develop -> (rebase) -> staging staging -> (rebase) -> release
为什么合并到 develop 必须用 cherry-pick？ 使用 merge 合并，如果有冲突，会产生分叉；dev-* 分支多而杂，直接 merge 到 develop 会产生错综复杂的分叉，难以理清提交进度。
而 cherry-pick 只将需要的 commit 合并到 develop 分支上，且不会产生分叉，使 git 提交图谱（git graph）永远保持一条直线。
再有，模块开发分支完成后，需要将多个 commit 合为一个 commit，再合并到 develop 分支，避免了多余的 commit，这也是不用 merge 的原因之一。
为什么合并到 staging/release 必须用 rebase？ release 译为变基，合并同样不会产生分叉。当 develop 更新了许多功能，要合并到 staging 测试，不可能用 cherry-pick 一个一个把 commit 合并过去。因此要通过 rebase 一次性合并过去，并且保证了 staging 与 develop 完全同步。
release 也一样，测试通过后，用 rebase 一次性将 staging 合并过去，同样保证了 staging 与 release 完全同步。
目前主流的前缀包括以下部分：
build：表示构建，发布版本可用这个 ci：更新 CI/CD 等自动化配置 chore：杂项，其他更改 docs：更新文档 feat：常用，表示新增功能 fix：常用：表示修复 bug perf：性能优化 refactor：重构 revert：代码回滚 style：样式更改 test：单元测试更改
npm install -g commitizen cz-conventional-changelog
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