我一直以为,时至今日,Git 知识应该已经足够普及,常用操作大家都知道,应该不需要分享。没想到换过几份工作之后,发现还有很多同学不清楚、乱用;一些新出的 git 分享文也写得乱七八糟,槽点满满。于是我决定结合之前在 Code.fun 建立的 Git 规范,和分享过的常见操作整理出来,作为虎年兔年承上启下的文章,贡献给大家。
Git 分享计划
本系列计划分成三篇文章:
- Git 团队规范(本文)
- 常见 Git 问题解决
- Git 推荐配置与小技巧
Git 使用原则
- 保障分布式开发:每个人都在自己的分支上开发;可以随时切换不同分支。
- 保障历史记录有价值:只保留有价值的 commit,不必要的 commit 应该在合并前 squash。可以通过回溯 commit message,了解到某行代码的意图,做出合理推断。
- 减少未来操作成本:只保留一条历史树,不使用 merge 造成混乱的图谱。以便在发版时不因为和代码耽误时间。
分支设计
Code.fun 是一家小厂,采用敏捷开发模式,所以不需要维护太多分支。大体上,我们只维护两大类分支:发布分支:master、dev;开发分支:每个人根据需求切出自己的分支进行开发。
- 正式版本代码放在 master 分支,并且公开发布上线。
- 迭代中的代码合并到 dev 分支,可能也会提供 dev 环境给部分喜欢尝鲜的用户。
- 迭代结束后,将 dev 合并回 master,并发布正式版。
- 启动新迭代,产生新的 dev 分支。
单线分支原则
为了保证版本管理的有效性,我们应尽力保持 只有一条线 的版本历史。为此
有以下注意事项:
- 保证本地
dev
与中心仓库一致。 - 开发时,从
dev
分支创建开发分支。- 如果需求较大、开发时间较长,建议大家经常 rebase,保持和 dev 同步。
- 合并前:
- 更新本地的
dev
分支,与中心仓库一致。 - 将开发分支 rebase 到最新
dev
分支,即在开发分支上,运行git rebase dev
。
- 更新本地的
- 拉代码时,尽量使用
git pull --ff-only
,避免出现 merge commit。
开发规范
- 新需求启动时,需要创建一个分支进行开发。如果有多个参与者,可以根据实际情况,选择大家在同一个分支下进行开发,或者基于此分支创建更多的子分支进行开发。
- 分支名应该包含用户名,与分支名用
/
分隔,形如:{用户名}/{分支名称}
。 - 其中分支名称应该符合
{前缀}-{需求描述}
,如feature-新功能
。 - 常见的前缀有:
- feat(ure): 新功能
- (bug)fix: 修复 bug
- chore:构建过程或辅助工具的变更
- docs: 文档的变更
- style: 代码风格的变更
- ref(actor): 重构
- test: 测试的变更
- ver(sion): 版本更新
- text(ure): 文本的变更
- deps: 依赖变更,即为适配依赖产生的变更
- 提交时,commit message 也需添加合适的前缀,如:
feature: 支持点击
。 - 分支应随时推入公司仓库。
- 需求开发过程中,应尽早创建 PR。PR 完成前,加
[WIP]
前缀。 - 开发完成后,部署到测试环境自测。
- 请结合各公司不同的基础设施,进行部署和自测。之前我厂主要是 k8s、GitHub Actions 等。
- 自测后,邀请产品同学体验,邀请测试同学测试。
- 体验+测试通过,请其他同事帮忙做 code review。
- 修复问题,code review 通过后,再次更新本地
dev
分支,然后使用git rebase dev -i
,将开发分支变基到最新dev
分支,并 squash 掉价值较小的 commit,只保留有回顾价值的 commit。 - 接下来,建议引入自动化测试,进行回归测试。
- 使用
git push -f
将变基后的分支再次推入仓库,准备合并。 - 合并分支到
dev
。此过程若在 GitHub 上操作,只可以使用“Squash and merge“或”Rebase and merge“,不可以使用“Create a merge commit”。如果只打算保留 一个 commit,就用”Squash“。 - 迭代周期结束后,合入
master
,等待发版。合入后之前所有的开发分支均作废。
可以说,Git 是现代化软件开发的基础,各种操作规范都建立在 Git 规范之上,比如 CI/CD、自动化测试、Code Review 等等。学会 Git,采用合理的 Git 流程对稳定发布有很大帮助,建议大家都学好 Git、选用简单有效的 Git 规范构建更好的团队。
上面的规范不一定适应所有团队,但在我长期的开发实践中,这套规则很好的提升了开发效率、保证了代码质量,推荐给大家参考。
如果你对上文有问题,或者对 Git 有不同理解,欢迎留言评论。
发表回复