一个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做完整。
下述每个事项,都视为独立的事项,值得做单独的提交,而不要相互混杂一起提交。
下述事项,都不是独立的事项,建议不要单独提交。
消息 | 问题 |
---|---|
fix issue | 不明确 |
commit code | 废话一句 |
test pipeline | 用来测试的临时变更并不需要提交。 |
trigger build | 这个应该用CICD的手工触发功能,而不应该污染Git的提交历史。 |
分支的合理使用方式,取决于团队分工与协作模式。并不存在一种分支模型能够适用于所有的团队类型。每个团队应当根据自己团队内会实际遇到的问题来制定自己团队的分支模型。
同时,分支模型的高效应用,往往并不是一个纯粹的流程合理性问题,也会依赖工具链的成熟度与成员的熟练度。脱离团队状态和企事业环境制定分支管理模型也是不可取的。
TrunkFlow[1]和GitFlow[2]之间的战争是不会停息的。因为双方的愿景和价值观是不可调和的。然而,对于特定的项目和团队,哪个分支流程更加适用,一般是比较明确的。
单人开发、测试覆盖率高的项目可以使用TrunkFlow。
多人协作、依赖比较多,需要与QA/QE协作的项目,一般建议使用GitFlow。每个人使用自己的开发分支。
至于是否能做到持续发布,更多的是取决于团队的成熟度和项目本身的需要。而不是GitFlow和TrunkFlow之间的选择。
使用GitFlow需要遵循以下基本原则:
同时建议:
使用TrunkFlow需要遵循以下原则:
在GitFlow中,当个人工作分支,与主分支存在冲突时,优先使用rebase解决,以便维护更可读的变更历史。当一个分支,已经被多人共享使用后,且团队成员git的熟练度不高时,则不再建议使用rebase,以免对他人产生不必要的额外负担。
在传统的软件开发过程中,正常的发布周期以月计。为了能让紧急的错误修复能尽快地发布到生产环境中,以不同于正常流程的方式,部署到生产环境中去,于是有了Hotfix的流程。
但是随着DevOps理念的推广,正常发版的流程与效率已经得到了极大的提高,在DevOps理念应用比较到位的企业,基本上可以做到每天数次发版。这时Hotfix与正常发版的时效上的差别,可以缩短到了几分钟之内。这时,分别为Hotfix和正常发版制定不同的流程的成本收益就需要仔细评估了。