2023 Git 必备知识(一):常用团队规范

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

Git 分享计划

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

Git 使用原则

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

分支设计

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

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

单线分支原则

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

  1. 保证本地 dev 与中心仓库一致。
  2. 开发时,从 dev 分支创建开发分支。
    • 如果需求较大、开发时间较长,建议大家经常 rebase,保持和 dev 同步。
  3. 合并前:
    1. 更新本地的 dev 分支,与中心仓库一致。
    2. 将开发分支 rebase 到最新 dev 分支,即在开发分支上,运行 git rebase dev
  4. 拉代码时,尽量使用 git pull --ff-only,避免出现 merge commit。

开发规范

  1. 新需求启动时,需要创建一个分支进行开发。如果有多个参与者,可以根据实际情况,选择大家在同一个分支下进行开发,或者基于此分支创建更多的子分支进行开发。
  2. 分支名应该包含用户名,与分支名用 / 分隔,形如:{用户名}/{分支名称}
  3. 其中分支名称应该符合 {前缀}-{需求描述},如 feature-新功能
  4. 常见的前缀有:
    • feat(ure): 新功能
    • (bug)fix: 修复 bug
    • chore:构建过程或辅助工具的变更
    • docs: 文档的变更
    • style: 代码风格的变更
    • ref(actor): 重构
    • test: 测试的变更
    • ver(sion): 版本更新
    • text(ure): 文本的变更
    • deps: 依赖变更,即为适配依赖产生的变更
  5. 提交时,commit message 也需添加合适的前缀,如:feature: 支持点击
  6. 分支应随时推入公司仓库。
  7. 需求开发过程中,应尽早创建 PR。PR 完成前,加 [WIP] 前缀。
  8. 开发完成后,部署到测试环境自测。
    • 请结合各公司不同的基础设施,进行部署和自测。之前我厂主要是 k8s、GitHub Actions 等。
  9. 自测后,邀请产品同学体验,邀请测试同学测试。
  10. 体验+测试通过,请其他同事帮忙做 code review。
  11. 修复问题,code review 通过后,再次更新本地 dev 分支,然后使用 git rebase dev -i,将开发分支变基到最新 dev 分支,并 squash 掉价值较小的 commit,只保留有回顾价值的 commit。
  12. 接下来,建议引入自动化测试,进行回归测试。
  13. 使用 git push -f 将变基后的分支再次推入仓库,准备合并。
  14. 合并分支到 dev。此过程若在 GitHub 上操作,只可以使用“Squash and merge“或”Rebase and merge“,不可以使用“Create a merge commit”。如果只打算保留 一个 commit,就用”Squash“。
  15. 迭代周期结束后,合入 master,等待发版。合入后之前所有的开发分支均作废。

可以说,Git 是现代化软件开发的基础,各种操作规范都建立在 Git 规范之上,比如 CI/CD、自动化测试、Code Review 等等。学会 Git,采用合理的 Git 流程对稳定发布有很大帮助,建议大家都学好 Git、选用简单有效的 Git 规范构建更好的团队。

上面的规范不一定适应所有团队,但在我长期的开发实践中,这套规则很好的提升了开发效率、保证了代码质量,推荐给大家参考。

如果你对上文有问题,或者对 Git 有不同理解,欢迎留言评论。


已发布

分类

作者:

评论

《“2023 Git 必备知识(一):常用团队规范”》 有 3 条评论

  1. […] Git 常用团队规范 […]

欢迎吐槽,共同进步

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据

%d 博主赞过: