一些编程规范
超详细的Git提交规范引入指南 - 掘金 (juejin.cn)
工作流图:
1. 永久分支:Master分支与Develop分支
- Master分支上的Commit都有对应的Tag。
- Develop分支与Master分支是两个永久存在的分支,从公Master拉取Develop分支。
- Develop分支不直接合并到Master分支。
- Master分支与线上版本保持一致。
- Develop分支是自动构建分支,它总是保有当前即将发布或是已经发布的代码,是确定的下一次将要通过Release分支合并到master上的代码。
2. 临时分支: Feature
- 当需要开发新的特性时,从Develop分支拉取Feature分支。
-
命名规范:
标准Git flow 认为Feature分支可以是,除以master, develop, release-, 和 hotfix-_ 开头的任何串。
在此我们规定,Feature分支命名规范以feat-开使。
- 生命周期:开发中存在,在合并到develop后或是丢弃后,便删除。
- 通常只在开发者的仓库中存在,origin中没有Feature分支。(不采纳这条限制,多人合作需要Feature上推到origin)
- Feature分支做完后(做完是值完成了主体功能,完成了大部分测试与bug的修复,可以存在少量的非重要bug),确定为当前上线的版本后,便可合并回Develop, 合并完分支后一般会删点这个Feature分支,也可以保留。
到这里,一个Feature分支的生命周期便结束了。
3.临时分支: Release
Release分支基于Develop分支创建,可以在Release分支上测试,修改Bug等。
同时,其它开发人员可以基于Develop开发新的Feature (记住:一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
发布Release分支时,合并Release到Master和Develop, 同时在Master分支上打个Tag记住Release版本号,删除Release分支。
4.临时分支hotfix:
hotfix分支基于Master分支创建,开发完后需要合并回Master和Develop分支,同时在Master上打一个tag
Git Flow 抽象模型
在使用的过程中一定要注意到数据流的流动方向。
下面给出Git Flow 的抽象模型,让大家能更加直观的把握、灵活的运用于实践中。
Feature分支流程
1 当有新的特性需要开发时,从Develop分支拉取Feature分支。
2 Feature分支在经过开发、测试后,确定为当前即将发布版本之后,便可合并到Develop分支,并删除Feature分支。
3 向Develop分支合并后,创建对应的Release分支,这可以对应一个或是多个Feature。
4 在Release上完成次要bug修复、发版配置等之后,便可合并到Develop与Master(Master上的合并需要加上tag)。
hotfix分支流程 与 release分支流程
1 它们都具有两个合并分支,Develop分支与Master分支。
2 hotfix拉取于Master分支。
3 release拉取于Develop分支。
4 hotfix是为解决线上严重问题而生。
5 release是为特性发布、工程配置、少量bug测试等问题而生。
release过后常规bug修复
release发布前,该特性引入的常规bug是在其上修改的。
对于release发布后,或是其它特性引入的bug,我们引入以"bugfix-"为开头的新特性。
至此我们基本遵守了标准 Git Flow 开发模型。
做了一个扩充:引入以"bugfix-"为开头的新特性,支持release发布后在Develop上发现的bug常规bug。
做了一个限制:Feature分支命名规范以“feat-”开始。
完整的数据流图与命名规范
格式: prename_postname
如 hotfix-5.11 , feat-5.11 , release-5.11 (5.11 为版本或是特性名称)
bugfix-图片上传(针对功能命名) , bugfix-5.11 (针对某版本或是特性命名)
master分支
master是项目第一个被创建的分支。
每一个向master的合并,都对应一个经过严格测试的主观稳定的线上版本。
它是hotfix-分支的上游分支。
hotfix-分支
当线上版本出现严重的bug时,需要从master上选取特定的tag拉取代码。
在完成测试具备上线条件后,在hotfix-分支上完成版本的发布。
经灰度发布后,先合并到master,再合并到develop分支。
这两个合并步骤是不可分的,是一个事务。亦可称为同时合并到master分支和develop分支。
develop分支
develop分支在git flow 中承担了最为复杂与重要的任务。
它是feat-分支、release-分支,和bugfix-分支的起点。
是代码的同步中心,其它任何分支,都是经过develop分支完成代码同步的。
feat-分支
feat-分支是研发分支,源于develop分支,终于develop分支。
在feat-分支完成所有的新功能研发,多少bug的修复与优化工作。
在确定为会在下一个版本发布时,便可以合并到develop分支。
在develop分支上有一个或是多个合并的未上线的feat-分支时,可以选择拉取release-分支,进入release阶段。
release-分支
release-分支承载了发布中项目的配置,一定bug的修复,优化等工作。
创建release-分支有两个目的:
尽快向develop分支合并确定的下版feat-分支,极大的提高了研发的并发度;
经测试、发布、审核,进入灰度后,直到确定为不再回滚正式发布后,合并到master与develop分支。
它维护了长时间窗口等待期,确保master与线上版本的一致。
bugfix-分支
可被视为特殊的feat-分支。
⚠️⚠️⚠️分支操作注意事项
KenChoi:为什么你应该停止使用 Git rebase 命令
只能对自己的私有分支做rebase操作。
凡涉及到几大共有分支(master, develop, release-, hotfix-_和 bugfix-)上的commit的合并,
必须使用merge,禁止使用rebase。严格禁止共有分支上的提交id变更。
其它分支可以使用rebase,合并到develop分支,但是只要提交到了develop,
所有的commit就属于develop分支,禁止再使用rebase操作。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)