Gitブランチ規約: 1. developブランチからfeatureブランチへ変更を取り込むを「マージコミット」方式を推奨するように変更

documents/forGitBranch/git_branch_standards.md

@@ -240,7 +240,7 @@ featureブランチで実現する機能を複数人で開発する場合に使
 
 マージ戦略とは、複数のブランチ間で生じた変更の取り込み方針を指す。
 
-具体的には次の3ケースそれぞれで、「マージコミット」「リベース」「スカッシュマージ」のどれを採用するか判断する。
+具体的には次の3ケースそれぞれで、「マージコミット」 「リベース」 「スカッシュマージ」のどれを採用するか判断する。
 
 1. developブランチからfeatureブランチへ変更を取り込む
 2. featureブランチからdevelopブランチへ変更を取り込む
@@ -258,22 +258,23 @@ featureブランチでの作業中に、developブランチが更新された場
 
 developブランチの変更をfeatureブランチに取り込む方法には、下表の2つの方法が存在する。
 
-機能ブランチに対して開発ブランチの変更を取り込む方法は「マージ」「リベース」2つの方法が考えられる。
+機能ブランチに対して開発ブランチの変更を取り込む方法は「マージ」 「リベース」2つの方法が考えられる。スカッシュマージはこのケースでは選択できない。
 
 | 1. マージコミット                                                                                         | 2. リベース                                                                                                                             |
 | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
 | <div class="img-bg-transparent"> ![マージ](img/merge_strategy_develop_to_feature_merge.drawio.png) </div> | <div class="img-bg-transparent"> ![リベース](img/merge_strategy_develop_to_feature_rebase.drawio.png) </div>                            |
 | `get fetch & git merge`（≒ `git pull`）。マージコミットが作成される                                       | `get fetch & git rebase`（≒ `git pull --rebase`）。最新の開発ブランチの先頭から新たにコミットを作りなされ、マージコミットは作成されない |
 
-本規約の推奨は「2. リベース」である。
+本規約の推奨は「1. マージコミット」である。
 
 理由は次の通り。
 
-- マージコミットが作成されると履歴が複雑になり、レビューアの負荷が高まる
-- スカッシュマージはこのケースでは選択できない
-- コンフリクトリスクは、マージ・リベース問わず発生するもので、リベースの選択による悪影響は存在しない
+- リベース方式で設定すべき `rerere.enabled` オプションを有効にしても、1度解消したコンフリクトの再対応をゼロにすることはできないため
+- マージコミットが作成され履歴が複雑になるが、1度解消したコンフリクトの再対応がゼロにできる点を優先する
 
-この選択にあたり、以下の設定を行う。
+::: tip リベース方式を採用する場合
+
+もし、リベース方式を採用する場合は、以下の設定を行う。
 
 1. `git pull` 時の挙動がリベースになるよう `git config pull.rebase true` を実行する
 2. developブランチの変更を取り込む場合、同じコンフリクトの解消を何度も求められることを解消するため、`git config rerere.enabled true` を実行する
@@ -285,9 +286,11 @@ developブランチの変更をfeatureブランチに取り込む方法には、
      - `--force-with-lease`: ローカルのリモート追跡ブランチの ref とリモートの ref を比較し、ローカルの状態が最新でない場合（プッシュ先のリモートブランチに変更が入ったが、ローカルで `git fetch` していない場合）は、プッシュに失敗する。逆にいうと、プッシュ前に `git fetch` を実行済みの場合は、リモートの変更を上書きする形で強制プッシュができてしまうため、これを防ぐには `--force-if-includes` フラグを併用する
      - `--force-if-includes`: リモート追跡ブランチの変更がローカルに全て取り込まれていない場合は、プッシュに失敗する。これにより意図せず他の人のコミットを上書きすることを防ぎつつ、必要な変更を強制的にプッシュすることができる
 
+:::
+
 ::: tip 強制プッシュでレビューコメントは消えるのか？
 
-強制プッシュすることにより、レビューコメントが消えてしまわないかという懸念を聞くことがある。2024年7月に実施した調査結果では問題なかった。
+強制プッシュすることにより、レビューコメントが消えてしまわないかという懸念を聞くことがある。2024年7月に実施した調査結果では問題なかった。特にリベース方式では重要である。
 
 - a.履歴保持: 強制プッシュを行い、GitHub投稿したレビューコメントが履歴として何かしらのページで取得できるかどうか。GitHubではConversationタブで確認
 - b.行単位の紐づけ（該当行の変更なし）: レビューコメントが付けられた行とは別の変更を行い、強制プッシュしたときにレビューコメントの紐づけが残るかどうか。GitHubではFile chagedタブで確認