app branching strategy
1.0.0
なぜSを理解していますか？
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ためにプラグに？ Merge-master.ymlすべてのマージにマスターするたびに、フルバージョンを更新します。既存のバージョンが以前の日付である場合、主要なマイナーバージョンが変更されます。そうしないと、パッチ番号のみが増加します。
例：
既存のバージョン： 2301.25.02
2023年1月25日に新しいコミットがプッシュされた場合、バージョンは2301.25.03になります
2023年1月26日に新しいコミットがプッシュされた場合、バージョンは2301.26.00なります
release/**？ On-Merge-release.yml
release*すべてのコミットでrelease*ブランチでパッチ番号を更新します
release/**にmasterに押し込みます？ On-Merge-Release.yml release*はauto-backmerge/<pr_number>ブランチを介して、対応するPRをmasterにトリガーします。
競合がない場合、PRは自動的にマージされます
？ prepare-a-release.yml最新のマスターからリリースブランチを作成し、正しいバージョンをブランチ名にします。
アクション
？ create-tagged-release.ymlタグ適切なバージョンタグとリリースノートを使用して、リリースブランチで最新のコミット
アクション
%% {init：{'gitgraph'：{'mainbranchname'： 'master'、 'showcommitlabel'：true}}} %%
gitgraph
コミットID：「？2301.25.00」
ブランチフィックス/フレームバグ
コミットID：「ロジックを修正」
コミットID：「UIを修正」
チェックアウトマスター
ブランチ機能/DM
コミットID：「DBを追加」
コミットID：「ソケットの追加」
チェックアウトマスター
マージフィックス/フレームバグID：「PR：フレームバグ」
コミット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
マージFIX/リリースバグID：「PR：リリースバグ」
チェックアウトリリース/V-2301.25
Branch Auto-Backmerge/Release-Bug
マージマスターID：「ブランチを更新」
チェックアウトリリース/V-2301.25
コミットID： "？2301.25.03"タグ： "V-2301.25.03"
チェックアウトマスター
マージAuto-Backmerge/Release-Bug 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"
ブランチホットフィックス/クラッシュ
コミットID：「クラッシュを修正」
チェックアウトリリース/V-2301.16
Hotfix/Crash IDのマージ：「PR Crash」
コミットID： "？2301.16.05"
ブランチホットフィックス/バグ
コミットID：「バグを修正」
チェックアウトリリース/V-2301.16
hotfix/バグIDのマージ：「PRバグ」
コミットID： "？2301.16.06"タグ： "V-2301.16.06"
線形履歴は、さまざまな理由で望ましいです。すべてが再びシンプルさになります。
1つのトランクとマージするスカッシュのみを可能にすることは、線形履歴を実現する最も簡単な方法です。誰も考える必要はありません、正しいことは自動的に起こります。
また、一般的に、人々はメッセージをコミットするよりもPRタイトルに関してより良い規律を持っているので、あなたの変更ログもよく見えます。
サーバーアプリとは異なり、モバイルアプリのリリースプロセスは長くなる傾向があります。途中で安定性とメトリックを観察しながら、10％> 20％> 20％> 50％> 100％に徐々にロールアウトする場合、 2週間以上かかることがよくあります。
一方、貢献者は、今すぐ習得するために合併しても安全かどうかを曖昧にするべきではありません。
リリースが作成され、コミットにタグ付けされると、目的はありません。そのため、リリース後に削除します。
ガント
タイトルアプリの開発とリリース
dateformat yyyy-mm-dd
ティックインターバル3日
セクション開発1
機能2：A、2022-01-13、15D
マスターにマージ：クリティカル、マイルストーン、a、0dの後
セクション開発2
機能1：B、2022-01-12、2d
マスターにマージ：マイルストーン、b、0dの後
ライブラリのアップグレード⬆️：L、2022-01-16、1d
マスターにマージ：l、0dの後、クリティカル、マイルストーン
フィーチャー1を修正しますか？：B2、R1、2dの後
リリースするためにマージ：マイルストーン、b2、0dの後
フレームワークアップグレード⬆️：F、2022-01-22、1d
マスターにマージ：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 ）は、ライブラリにとって理にかなっています。あなたの図書館の消費者は、変化が発生したときとそうでないときを知りたいと思っています。パッケージマネージャーは、このコンベンションを利用して、依存関係を安全にアップグレードします。モバイルアプリユーザー /アプリストアには、アプリバージョンにはそのような期待がありません。彼らはかろうじて気にしません。
私のチームは、日付ベースのバージョンスキームを1年以上使用してきましたが、それは素晴らしいことです！
