Gitブランチの操作誤りによるコミット混入の原因と対策

【トラブルシュート記録】Git構成管理の不整合とリスクベースの意思決定

1. 発生した事象

本来、別々のプルリクエスト（PR）として管理・マージすべきだった以下の2つの独立
したタスクが、意図せず単一のブランチ（fix/vercel-build-
error）に混入し、1つのPRとしてまとめてマージされてしまいました。

• 7月18日：ドキュメント作成および修正（interview-faq.md,
  README.md）
• 7月21日：Vercelのビルドエラー解消（examples
  フォルダの削除）

結果として、GitHub上のコミット履歴において、ドキュメント修正コミットの直後に通
常表示されるはずの「Merge pull request」の履歴が存在しない状態となりました。

2. 原因分析

• ブランチの作成元ミス：7月21日の作業開始時、main
  からブランチを切るべきところを、未マージの feature/readme-and-faq
  ブランチに滞在したまま新規ブランチを作成してしまい、ドキュメントの修正履歴を引き
  継いでしまいました。
• マージ衝突（コンフリクト）への過度な懸念：複数のブランチを並
  行してマージすることによる衝突を懸念し、「ブランチを分ける」というGit構成管理の基
  本原則に対する判断が鈍りました。
• AI指示の盲信：AIが提示した「目先のタスクを解決するためのコマ
  ンド」を、ローカルのブランチ状態（コンテキスト）と照らし合わせずに実行してしまい
  ました。

3. 対策と再発防止策

• トピックブランチの徹底：「1ブランチ＝1テーマ」を厳守し、異な
  るファイルや無関係なタスクは必ず別ブランチで並行管理します。異なるファイルへの変
  更であれば、Gitが自動で安全にマージするため、コンフリクトを恐れる必要はないことを
  理解しました。
• ブランチ作成ルーティンの確立：新規ブランチを作成する際は、必
  ず以下の手順を実行することをルール化します。

git checkout main
    git pull
    git checkout -b <新規ブランチ名>

4. QAエンジニアとしての学び（教訓）

• プロセスの検証と批判的思考：開発プロセスやツール（AIを含む）
  の指示を鵜呑みにせず、「現在の環境状態に対して本当にこの手順が適切か」を常に検証
  する、QAに必要な「批判的思考」の重要性を再認識しました。
• リスクベースの意思決定：発生した履歴の不整合に対し、見栄えを
  良くするために force push
  等のハイリスクな操作（実務において他メンバーの環境を破壊する禁忌）で履歴をきれいにす
  るのではなく、実務上のリスクを考慮して「履歴はそのまま維持し、プロセス改善で再発
  防止を図る」という、リスク管理に基づいた判断をしました。