internal review feedback

documents/forGitBranch/Gitブランチフロー規約.md

@@ -25,15 +25,20 @@ meta:
 
 導入に際して行う、GitやGitHub/GitLabの環境設定は、[推奨設定](recommended_settings.md)ページに記載している。
 
-# ブランチ運用パターン
+# ブランチ戦略の選定
 
 本ドキュメントで想定する各ブランチ役割については[ブランチの整理](each_branch.md)に記載する。
 
+ブランチ戦略は以下の方針で選定する。
+
+- できるかぎりシンプルなモデルを選択し、運用コストを下げる
+- プロジェクトのフェーズや体制に応じて、変更を許容する
+
 現実的に利用する可能性が高いブランチの運用パターン３つ示す。
 
-基本的には運用コストが最小になるパターンを選択し、プロジェクトの体制に応じて運用を変更する。
+選定を記載順で導入を検討する。
 
-（例） GitHub Flow → Lite GitLab Flow → GitLab Flow
+- GitHub Flow → Lite GitLab Flow → GitLab Flow
 
 | 名称             | 利用ブランチ                                          | 概要                                                                                                                                                                                                                                                                                                                                                                                                                        | 運用コスト | 使い所                                                                                               |
 | ---------------- | ------------------------------------------| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------------------- |
@@ -55,18 +60,18 @@ meta:
 当然、`develop2`はこれらの変更を加味して大型リリース向け開発を進める必要があるので、`develop`のmainブランチ反映されるたびに`develop`から`develop2`への同期を行う必要がある。  
 `develop`から`develop2`への同期は以下の様に行う。
 
-- rebaseとしてしまうと`develop2`を元にfeatureブランチを作成して開発している開発者が混乱することになるため、マージコミットにて同期を行う。  
+- リベースとしてしまうと`develop2`を元にfeatureブランチを作成して開発している開発者が混乱することになるため、マージコミットにて同期を行う。  
 - 誤操作を避ける目的でcherry-pickは行わない。
 
 ![release multi develop branch](img/branch_strategy_release_multi_develop.drawio.png)
 
 develop2のリリースは以下の手順で行う。
 
 1. `develop`から`develop2`へマージコミットによって同期を行う。（2でコンフリクトが起こらないよう、前準備の意味合いで実施する。）
-2. `develop2`から`develop`にmergeを行い、その後は通常のリリースフローに従う
+2. `develop2`から`develop`にマージを行い、その後は通常のリリースフローに従う
 3. 問題なくリリースが完了し次第、`develop2`を削除する
 
-`develop`から`develop2`へmerge後、`develop2`を`main`ブランチに反映させる手順も考えられるが、`develop2`から`develop`へのマージとすると以下のメリットがある。
+`develop`から`develop2`へマージ後、`develop2`を`main`ブランチに反映させる手順も考えられるが、`develop2`から`develop`へのマージとすると以下のメリットがある。
 
 - 本番環境（=`develop`）との差分を把握することができる
 - より一般的な名称である `develop` ブランチのみ残るため、新規参画者フレンドリーである
@@ -82,9 +87,9 @@ develop2のリリースは以下の手順で行う。
 featureブランチのマージ後、マイナーバージョン（あるいはパッチバージョン）を上げたタグをコミットし、本番環境へリリースする。  
 ※この例ではversion1とversion2が別リソースとして動いていることを前提としている。同一リソースで複数バージョンが稼働する場合はversion2のブランチで対応を行う必要がある。
 
-# マージ戦略
+# マージ戦略の選定
 
-マージ戦略とは、複数のブランチ間でコードの変更を統合する際に使用される方法やポリシーを指し、以下の事項に影響を与えます。
+マージ戦略とは、複数のブランチ間でコードの変更を統合する際に使用される方法やポリシーを指し、以下の事項に影響を与える。
 
 - プロジェクトのコミット履歴の管理
 - コンフリクトの解決
@@ -100,7 +105,7 @@ featureブランチのマージ後、マイナーバージョン（あるいは
 1. 開発中の機能ブランチに対してメインの開発ブランチの変更をどう取り込むか
 2. メインの開発ブランチに開発およびレビューが完了した機能ブランチをどう取り込むか
 
-## 1. 機能ブランチにメインの開発ブランチの変更を取り込む
+## 1. 機能ブランチに開発ブランチの変更を取り込む
 
 複数人により同時並行的に開発が進む場合、特定の機能ブランチで開発を進めている最中に、メインの開発ブランチがアップデートされることはよく起こる。
 
@@ -148,7 +153,7 @@ featureブランチのマージ後、マイナーバージョン（あるいは
 | AWS CodeCommit | 残る           | 消える                            | 消える                              | 強制プッシュ関係なく、最新のコミットに対してのみレビューコメントが紐づく。そのため、新しいコミットをPushすると、過去につけたレビューコメントがファイル詳細から消えたように見える |
 :::
 
-## 2. メインの開発ブランチに機能ブランチの変更を取り込む
+## 2. 開発ブランチに機能ブランチの変更を取り込む
 
 プルリクエストを経由して、開発が完了した機能ブランチをメインの開発ブランチに取り込むためには、GitHub（GitLab）上でプルリクエスト（マージリクエスト）を経由する運用を前提とする。
 
@@ -190,7 +195,7 @@ https://zenn.dev/daku10/articles/github-merge-guardian
 
 ## 追い抜きリリース
 
-以下のような状況とします。
+以下のような状況とする。
 
 - 2つのチケット（issue-312、issue-394とする）があり、どちらも同じファイルの修正を含む
 - 先にissue-312がdevelopにマージされ、その後に着手されたissue-394がマージされた
@@ -220,7 +225,7 @@ https://zenn.dev/daku10/articles/github-merge-guardian
 
 ![hotfixで追い抜き](img/release_overtaking_hotfix.drawio.png)
 
-# コミットメッセージ
+# コミットメッセージ規則
 
 Gitのコミットメッセージは原則自由とする。理由は以下である。
 
@@ -232,24 +237,24 @@ Gitのコミットメッセージは原則自由とする。理由は以下で
 
 - [コミットメッセージ規約](commit_message_rule.md)
 
-# ブランチ名
+# ブランチ命名規則
 
 ブランチ名の命名規則は、[ブランチの整理](each_branch.md)の記載内容に従うこと。
 
-# ラベル
-
-TODO ラベルについて方針を追加する。（ラベルを利用することで、issue, プルリクエストを分類することができる。適切に設定することでリリースノート作成時に有用である。）
-
-https://docs.github.com/ja/issues/using-labels-and-milestones-to-track-work/managing-labels
-
-# タグ
+# タグ規則
 
 Gitにはタグ機能があり、リリースポイントとしてタグを作成する運用とする。
 
 これにより、リリースしたアプリケーションやライブラリに何か不具合があれば、切り戻しや原因追求が容易になる利点がある。
 
 タグを利用するうえでの運用ルール・命名規則などは[タグ規則](git_tag.md)を参考にする。
 
+# ラベル規則
+
+TODO ラベルについて方針を追加する。（ラベルを利用することで、issue, プルリクエストを分類することができる。適切に設定することでリリースノート作成時に有用である。）
+
+https://docs.github.com/ja/issues/using-labels-and-milestones-to-track-work/managing-labels
+
 # 参考1:ローカルでの作業例
 
 gitコマンドでの作業例を記載する。リモートブランチへのプッシュは、`--force-with-lease --force-if-includes` オプションを付けることを必須とする。