app branching strategy
1.0.0
了解为什么？
master - >最新和最伟大的开发人员测试代码没有其他永久的树干。
feature/<feature_name>fix/<bug_title>release/v-<version.major>.<version.minor>auto-backmerge/<pr_number>用于提高PR，以掌握每一个更改以释放分支机构 YYMM.DD.NN
NN补丁编号
2302.01.04 ： 2301.25.00
master？ on-merge-master.yml在每次合并中以掌握我们更新完整版本。如果现有版本是上一个日期，则将修改专业的次要版本，否则仅增加补丁编号。
例子：
现有版本： 2301.25.02
如果2023年1月25日推出新提交，则该版本将变为2301.25.03
如果在2023年1月26日推出新提交，则该版本将变为2301.26.00
release/**？合并释放.yml
release*在每个提交中，我们都会更新版本release*分支上的补丁编号
release/**推向master ？ on-merge-release.yml release*的每一个推力都会通过auto-backmerge/<pr_number>分支master相应的PR。
如果没有冲突，将自动合并公关
？ prepar-a-release.yml从最新的主人创建一个发行分支，并在分支名称中使用正确的版本。
动作
？创建标签释放.yml标记具有正确版本标签的发行分支中的最新提交和发行说明
动作
%% {init：{'gitgraph'：{'mainbranchname'：'master'，'showcommitlabel'：true}}};
Gitgraph
提交ID：“？2301.25.00”
分支修复/框架
提交ID：“修复逻辑”
提交ID：“修复UI”
结帐大师
分支功能/DM
提交ID：“添加DB”
提交ID：“添加套接字”
结帐大师
合并fix/frax-bug ID：“ pr：frames bug”
提交ID：“？2301.25.01”
结帐功能/DM
合并主ID：“拉手”
提交ID：“添加UI”
结帐大师
合并功能/DM ID：“ PR：功能DM”
提交ID：“？2301.25.02”
master （动作）切开master分支中的错误，然后转到步骤2 %% {init：{'gitgraph'：{'mainbranchname'：'master'，'showcommitlabel'：true}}};
Gitgraph
提交ID：“？2301.25.02”
分支机构/V-2301.25
结帐大师
提交ID：“ PR：新功能”类型：突出显示
提交ID：“？2301.26.00”
结帐版本/V-2301.25
分支修复/释放袋
提交ID：“修复错误”
结帐版本/V-2301.25
合并修复/释放点-BUG ID：“ PR：释放错误”
结帐版本/V-2301.25
分支自动折叠/释放烧伤
合并主ID：“更新分支”
结帐版本/V-2301.25
提交ID：“？2301.25.03”标签：“ V-2301.25.03”
结帐大师
合并自动折叠/释放烧伤ID：“ Backmerge”
结帐大师
提交ID：“？2301.26.01”
动作
一旦我们？在所有测试中，执行以上操作以标记发行分支的最新提交，并创建具有自动发行说明的GitHub版本。并将工件上传到应用商店
解决当前生产构建中的问题（ v-2301.16.01 ）
v-2301.16.01 >分支： release/v-2301.16 ）其余的与正常释放流相同
%% {init：{'gitgraph'：{'mainbranchname'：'Release/v-2301.16'，'ShowCommitlabel'：true}}}}};
Gitgraph
提交ID：“ 2301.16.04”标签：“ V-2301.16.04”
分支Hotfix/crash
提交ID：“修复崩溃”
结帐版本/V-2301.16
合并HotFix/Crash ID：“ PR Crash”
提交ID：“？2301.16.05”
分支hotfix/bug
提交ID：“修复错误”
结帐版本/V-2301.16
合并hotfix/bug ID：“ pr bug”
提交ID：“？2301.16.06”标签：“ V-2301.16.06”
由于各种原因，线性历史是可取的。一切都归结为简单。
仅允许南瓜与单个躯干合并是实现线性历史记录的最简单方法。没有人必须考虑，正确的事情会自动发生。
同样，总的来说，与公关标题相比，人们在公关头衔方面具有更好的纪律，因此您的变更记录看起来也不错。
与服务器应用程序不同，移动应用程序发布过程往往很长。如果我们将逐渐推出到10％> 20％> 50％> 100％的同时，同时观察稳定性和指标，则通常需要2周或更长时间。
同时，贡献者不应该歧义是否可以安全地合并以掌握。
一旦发布并标记了提交，它们就没有任何目的。这就是为什么我们在发布后删除它们的原因。
甘特
标题应用程序开发和版本
dateformat yyyy-mm-dd
tickinterval第3天
DEV 1节
功能2：A，2022-01-13，15d
合并到主人：Crit，Milestone，在A，0D之后
DEV 2节
功能1：B，2022-01-12，2D
合并到主人：里程碑，b，0d之后
图书馆升级⬆️：L，2022-01-16，1D
合并到主人：Crit，Milestone，在L，0d之后
修复功能1？：B2，R1，2D之后
合并释放：里程碑，B2之后，0d之后
框架升级⬆️：F，2022-01-22，1D
合并到主人：Crit，Milestone，在F，0D之后
部分发布
准备发行版2201.14：里程碑，b，0d之后
测试功能1：R1，B，4D之后
测试功能1：R2，B2之后，1D
推出2201.14.1 10％-100％：R3，R2，7D之后
准备版本2201.31：里程碑，2022-01-31，0D
合并掌握？即使释放正在进行，也很安全和鼓励
这是基于日期的版本管理方案，也是
semver比较兼容哪个版本大于其他版本2301.16.00 > 2212.31.07 ）最重要的是避免了这个问题 -我们什么时候发布此版本？永远，来自整个团队中的任何人
即使回答上述问题对您的团队并不那么重要，它也同样好，即使不是semver 。默认情况下，大多数团队使用。语义版本控制（ semver ）对于库是有意义的。图书馆的消费者想知道何时发生破裂的变化以及何时没有。包装经理利用本惯例可以安全地升级依赖性。移动应用程序用户 /应用商店对应用程序版本没有这种期望。他们几乎不在乎。
我的团队使用基于日期的版本操作方案已有一年多了，这很棒！
