一些编程规范

超详细的Git提交规范引入指南 - 掘金 (juejin.cn)

Git flow 规范 - 知乎 (zhihu.com)

工作流图:

1. 永久分支:Master分支与Develop分支

  1.  Master分支上的Commit都有对应的Tag。
  2. Develop分支与Master分支是两个永久存在的分支,从公Master拉取Develop分支。
  3. Develop分支不直接合并到Master分支。
  4. Master分支与线上版本保持一致。
  5. Develop分支是自动构建分支,它总是保有当前即将发布或是已经发布的代码,是确定的下一次将要通过Release分支合并到master上的代码。

2. 临时分支: Feature

  1. 当需要开发新的特性时,从Develop分支拉取Feature分支。
  2. 命名规范:

    标准Git flow 认为Feature分支可以是,除以master, develop, release-, 和 hotfix-_ 开头的任何串。

    在此我们规定,Feature分支命名规范以feat-开使。

  3. 生命周期:开发中存在,在合并到develop后或是丢弃后,便删除。
  4. 通常只在开发者的仓库中存在,origin中没有Feature分支。(不采纳这条限制,多人合作需要Feature上推到origin)
  5.  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操作。

posted @   白与花糖  阅读(14)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
点击右上角即可分享
微信分享提示