PRを切り直してCIを通すまでにやったこと

ゴール

• 「直近コミットだけをdevelopに入れたい」のに、PRが過去コミットを大量に抱えていた
• さらに新PRでCIが落ちていたので、CIが落ちない形に整える必要があった

PRは「コミット」じゃなく「ブランチの差分」

• GitHubのPRは baseブランチ（例: develop）と、PRブランチの差分を見ている
• だから PRに「余計なコミット」が入っている時は、
  • そのブランチが develop から分岐した位置が古い
  • もしくは別作業のコミットがそのブランチに混ざっている
    という状態になっている。

Squash merge は コミット1個にまとめるだけで、差分自体は全部入る。「余計な差分を入れない」には効かない。

切り直し方法

必要な変更だけを新ブランチへ“移植”する（cherry-pick or 作り直し）

• develop 最新から新ブランチを切る
• 欲しい変更だけをそのブランチに持ってくる
• そのブランチでPRを作る

この方法のメリット：

• PRに混ざる差分を最小化できる
• レビューしやすい
• 余計な履歴を持ち込まない

実際に詰まったポイントと対処

git switch develop ができない（ローカル変更がある）

現象：

• config/routes.rb の未コミット変更が残っていてcheckoutを拒否された

対応：

• まず git stash で退避する（安全）
• git stash push -m "wip"
• untrackedも含めるなら git stash push -u

cherry-pick で Gemfile.lock がコンフリクト

現象：

• cherry-pick したいコミットが lock を変えていて、develop 側と衝突

対応（安全寄り）：

• cherry-pick を諦めて bundle update brakeman を新ブランチ上でやり直す
• git cherry-pick --abort
• bundle update brakeman
• git add Gemfile.lock
• git commit ...

※ lock系は「そのブランチの依存関係に対して生成し直す」のが事故りにくい。

CIが落ちた原因

落ち方：

• db:create で PG::ConnectionBad: could not translate host name "db"
• → appコンテナから db が名前解決できない（CIでDNS/ネットワーク/起動順が不安定）

根本構造：

• workflowで docker compose up -d → docker compose exec app ... という流れ
• でも app は本来「サーバ常駐向け」のコンテナ設定（rdbg付き）で、CI用途と相性が悪い
• さらに exec は「起動済みコンテナ」に依存するので、立ち上がりタイミングで不安定になりやすい

CIを安定させた方針

方針：exec 依存をやめて、docker compose run --rm に寄せる

• up -d をやめる（常駐前提を捨てる）
• 1コマンド = 1コンテナ実行（CI向け）
• 後片付けは --rm で自動

workflowの変更例：

• Setupで：
  • docker compose run --rm app bundle install
  • docker compose run --rm -e RAILS_ENV=test app rails db:prepare
  • docker compose run --rm -e RAILS_ENV=test app rails assets:precompile
• Brakeman / Rubocop / RSpecも：
  • docker compose run --rm app ...
  • rspecは RAILS_ENV=test を明示

結果：

• db の名前解決に依存しにくくなり、CIが安定して通った

学び（まとめ）

• PRは「ブランチ差分」。混ざったら 切り直し（新ブランチ） が一番速い
• lockファイルは cherry-pick で揉めたら その場で更新し直すのが安全
• CIは exec 依存より run --rm の方が安定しやすい
• CIで RAILS_ENV=test を明示するのは「事故防止」