经历了好几个公司和开发团队,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。