merge-branch

ブランチをマージする

変更が共有ブランチに入るマージは、レビューの関門でもあります。変更を取り込む前に、プロジェクトで定められた原則（PRINCIPLES.md、AGENTS.md、CONTRIBUTING.md など）があれば、それに照らして変更を評価してください。

プロダクトに関する決定を、決して推測したり、代わりに下したりしないでください。 コンフリクトの解決や変更のレビューによって、お客様に表示される内容やプロダクトの動作、つまりどちらの動作を採用し、どのフローを残すかが、知らないうちに決まってしまうことがあります。その場合は作業を止め、最終的にお客様にどのような体験を提供するべきか、ユーザーに確認してください。理由を添えて解決案を提案し、決定はユーザーに委ねます。

影響範囲が広いものも同様です。 アーキテクチャ、データ、ドメインモデル、依存関係を作り変えるようなコンフリクトの解決など、共有ブランチに取り込んだ後の変更が難しいものは、マージ作業の中で独断で決めてはいけません。まず確認してください。

簡潔な言葉で確認してください。 質問1つにつき決定事項は1つにし、平易な言葉で、まず推奨案を示し、それぞれの選択肢がお客様にどう影響するかを説明します。複数の決定事項を1つの質問にまとめてはいけません。また、未回答の質問を残したままマージを進めてはいけません。

回答を記録してください。 マージ中にユーザーが下したプロダクトに関する決定はすべて、質問、選択した案、その理由をマージコミットのメッセージに記録します。次に git log を読む人が、決定の経緯を再構築しなくてもよいようにしてください。

以下では、<main> はメインの統合ブランチ（例：main または dev）を指します。

マージする前に

1. 取り込む変更を確認します。 git log --oneline <target>..<branch> と git diff --stat <target>...<branch> を実行し、重要な差分を読みます。各変更の意図がコミットメッセージで明確になっている必要があります。差分とメッセージから変更の意図が明らかでない場合は、推測せず確認してください。
2. 原則に照らしてレビューします。 特に次の点に注意してください。
   • 複雑さよりシンプルさを優先します。 不要な複雑さ（並行する仕組み、既存のものの二重化、汎用的な受け皿など）を持ち込む変更は、マージ後ではなく、マージ前に指摘して話し合います。
   • バグの原因になりうる要素を確認します。 よくあるものとして、状態の重複、タイムスタンプの比較、ユーザーに応答するスレッドでのブロッキング I/O、バイト単位のテキスト処理、未ローカライズの文字列があります。
3. ターゲットブランチが別のプラットフォーム向けに使われている場合、 取り込む変更がそれぞれのプラットフォームで何を意味するのか確認し、適用できないものがあれば記録します。記録先はマージコミット、またはプロジェクトでプラットフォーム対応の追跡に使用している場所とし、何もせずに終わる変更を放置してはいけません。
4. まず調査結果を報告します。 ブランチで行われる変更、不明な点、原則に反する点を列挙してください。指摘事項がマージを妨げるのか、後続作業とするのかは、ユーザーが決定します。

マージの方向を選ぶ

先に <main> をもう一方のブランチにマージするほうが容易な場合は、その旨を伝えてください。先にそのブランチを <main> にマージしてはいけません。 ブランチの存続期間が長い場合やコンフリクトが予想される場合は、通常この方法が適しています。まず <main> → ブランチの順にマージし、問題が起きても影響が限定される場所で解決と検証を行い、その後、きれいになったブランチを <main> にマージします。理由を添えて方向を提案し、ユーザーに確認してください。

マージする

• 両方の変更の意図を理解してコンフリクトを解決してください。機械的に片方を選んではいけません。コンフリクトから同じものが二重に実装されているとわかった場合は、単なるコンフリクトではなく、指摘事項として扱います。
• 作業中にユーザーが下したプロダクトに関する決定と、後続作業として受け入れることにした指摘事項はすべて、マージコミットのメッセージに記録します。
• マージ後は、ビルドを行い、変更に応じたテストを実行して検証します。検証したことと、検証していないことを明確に示してください。
• 求められない限り、プッシュしないでください。