新的 git 指南：我们已切换到常规提交

赋予团队尽可能多的自主权固然好，但制定一些全公司范围的指导方针也会有所帮助。这些指导方针在团队切换、开发多个产品或培训新同事时会有所帮助。

讨论、决定、重复

我们最近在visuellverstehen与所有软件开发者讨论了技术相关的话题。此次讨论的成果之一是新的 git 指南。经过短暂的讨论，我们正式切换到了约定式提交 (Conventional Commits)。

看到所有最新的提交都遵循新的语法，真是令人欣喜。我很好奇六个月或十二个月后我们会如何看待这一变化。我们肯定会再次讨论并做出更好的决定。

新的 git 指南

您可以在下面找到我们的 2022 年 11 月版 git 指南。

存储库

• 存储库应按如下方式命名：vvcode-name_of_project

分支

• 主分支应该命名为main
• 从事产品开发的人员决定是否要与其他分支合作
• 如果需要进一步的分支，建议在分支名称中添加问题编号和简称，例如：
  • 100-validation-errors
  • 101-basic-search
  • 102-german-translation
  • 103-live-deployment
  • 104-url-formatting

提交

• 我们使用来自常规提交的语法
• 提交消息包含以下前缀之一：
  • fix:修复错误
  • feat:引入新功能
  • chore:做出一般性改变
  • ci:致力于持续集成/持续部署
  • refactor:改进现有的源代码
• 提交信息应以当前形式书写
• 提交信息应该用英文书写
• 提交信息应该以小写字母开头
• 建议将问题编号添加到提交消息中
• 提交消息的实际示例：
  • fix: display validation errors properly, refs #100
  • feat: implement basic search, refs #101
  • chore: add correct german translation, refs #102
  • ci: repair live deployment, refs #103
  • refactor: unify URL formatting, refs #104
• 如果提交正在进行中，则应标记为：
  • fix: display validation errors properly (WIP), refs #100
  • feat: implement basic search (WIP), refs #101
  • chore: add correct german translation (WIP), refs #102
  • ci: repair live deployment (WIP), refs #103
  • refactor: unify URL formatting (WIP), refs #104