山维空间

标签： 规范

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

    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 有不同理解，欢迎留言评论。