2023 Git 必备知识（一）：常用团队规范

我一直以为，时至今日，Git 知识应该已经足够普及，常用操作大家都知道，应该不需要分享。没想到换过几份工作之后，发现还有很多同学不清楚、乱用；一些新出的 git 分享文也写得乱七八糟，槽点满满。于是我决定结合之前在 Code.fun 建立的 Git 规范，和分享过的常见操作整理出来，作为虎年兔年承上启下的文章，贡献给大家。

Git 分享计划

本系列计划分成三篇文章：

Git 使用原则

保障分布式开发：每个人都在自己的分支上开发；可以随时切换不同分支。
保障历史记录有价值：只保留有价值的 commit，不必要的 commit 应该在合并前 squash。可以通过回溯 commit message，了解到某行代码的意图，做出合理推断。
减少未来操作成本：只保留一条历史树，不使用 merge 造成混乱的图谱。以便在发版时不因为和代码耽误时间。

分支设计

Code.fun 是一家小厂，采用敏捷开发模式，所以不需要维护太多分支。大体上，我们只维护两大类分支：发布分支：master、dev；开发分支：每个人根据需求切出自己的分支进行开发。

正式版本代码放在 master 分支，并且公开发布上线。
迭代中的代码合并到 dev 分支，可能也会提供 dev 环境给部分喜欢尝鲜的用户。
迭代结束后，将 dev 合并回 master，并发布正式版。
启动新迭代，产生新的 dev 分支。

单线分支原则

为了保证版本管理的有效性，我们应尽力保持 只有一条线 的版本历史。为此
有以下注意事项：

保证本地 dev 与中心仓库一致。
开发时，从 dev 分支创建开发分支。
- 如果需求较大、开发时间较长，建议大家经常 rebase，保持和 dev 同步。
合并前：
1. 更新本地的 dev 分支，与中心仓库一致。
2. 将开发分支 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 有不同理解，欢迎留言评论。