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 ）對於庫是有意義的。圖書館的消費者想知道何時發生破裂的變化以及何時沒有。包裝經理利用本慣例可以安全地升級依賴性。移動應用程序用戶 /應用商店對應用程序版本沒有這種期望。他們幾乎不在乎。
我的團隊使用基於日期的版本操作方案已有一年多了，這很棒！
