¶ 提交（commit）
¶ 格式
一个Commit需要正确携带如下信息：
- 作者（Author）：代码的作者。指设计、定义代码逻辑的人，一般是代码编写者。参考Git Command
- 提交人（Committer）：代码提交人。有时代码并不一定由作者本人提交。
- 消息（Message）：简要描述提交的内容。每个Commit的消息最好有一定的区分度。
提交消息本身可以遵循一定的格式以表达更多的信息。如：
¶ 信息量
提交的消息（Message），需要描述代码变更的意图和目的，而不是描述做了什么。比如，以如下代码变更为例：
data class OrderInfoDTO(
val id: UUID,
++ val expireTime: Instant,
)
Add expireTime field to OrderInfoDTO class.
feat: JIRA-ID Expose expiring time to FE.
¶ 粒度
一个Commit只做一件事儿；一件事儿在一个Commit做完整。
下述每个事项，都视为独立的事项，值得做单独的提交，而不要相互混杂一起提交。
- 代码重构（包括格式化）
- 配置变更
- 某Bug的修复
- 依赖库与框架版本的升级
下述事项，都不是独立的事项，建议不要单独提交。
- “Fix typo”： 如果代码还没有合并，哪里有typo就把有问题的那个commit修掉。
- “Fix build”：如果代码还没有合并，最好从哪里坏的就从哪里修好。
- “Add more tests”：如果代码还没有合并，最好和前面的“add unit test for XXX”合并成一个commit。除非这次加的测试与之前的显著不同。比如这次加的是Integration Test。那么依然需要改善描述。
JIRA-1234 Rename FileManager to FileStore.
Revert commit " JIRA-1234 Rename FileManager to FileStore."
| 消息 | 问题 |
|---|---|
| fix issue | 不明确 |
| commit code | 废话一句 |
| test pipeline | 用来测试的临时变更并不需要提交。 |
| trigger build | 这个应该用CICD的手工触发功能，而不应该污染Git的提交历史。 |
¶ 分支管理
分支的合理使用方式，取决于团队分工与协作模式。并不存在一种分支模型能够适用于所有的团队类型。每个团队应当根据自己团队内会实际遇到的问题来制定自己团队的分支模型。
同时，分支模型的高效应用，往往并不是一个纯粹的流程合理性问题，也会依赖工具链的成熟度与成员的熟练度。脱离团队状态和企事业环境制定分支管理模型也是不可取的。
¶ 分支流程
TrunkFlow[1]和GitFlow[2]之间的战争是不会停息的。因为双方的愿景和价值观是不可调和的。然而，对于特定的项目和团队，哪个分支流程更加适用，一般是比较明确的。
单人开发、测试覆盖率高的项目可以使用TrunkFlow。
多人协作、依赖比较多，需要与QA/QE协作的项目，一般建议使用GitFlow。每个人使用自己的开发分支。
至于是否能做到持续发布，更多的是取决于团队的成熟度和项目本身的需要。而不是GitFlow和TrunkFlow之间的选择。
¶ 分支合并
使用GitFlow需要遵循以下基本原则：
- 只能将工作分支（feature branch）合并到开发分支（develop）。而不能将开发分支合并进工作分支。
同时建议：
- 如果开发分支上现有变更的发布时间不确定。建议从master分支拉工作分支。以免被开发分支上的变更阻碍。
使用TrunkFlow需要遵循以下原则：
- CI不通过，不能合并到trunk。
¶ 分支冲突
在GitFlow中，当个人工作分支，与主分支存在冲突时，优先使用rebase解决，以便维护更可读的变更历史。当一个分支，已经被多人共享使用后，且团队成员git的熟练度不高时，则不再建议使用rebase，以免对他人产生不必要的额外负担。
¶ Hotfix
在传统的软件开发过程中，正常的发布周期以月计。为了能让紧急的错误修复能尽快地发布到生产环境中，以不同于正常流程的方式，部署到生产环境中去，于是有了Hotfix的流程。
但是随着DevOps理念的推广，正常发版的流程与效率已经得到了极大的提高，在DevOps理念应用比较到位的企业，基本上可以做到每天数次发版。这时Hotfix与正常发版的时效上的差别，可以缩短到了几分钟之内。这时，分别为Hotfix和正常发版制定不同的流程的成本收益就需要仔细评估了。