「マージしたのに直らない」— デプロイ元ブランチと定期実行ブランチが違う罠

誰向けか

1つのリポジトリで Web アプリ本体と定期バッチ（GitHub Actions の schedule）の両方を動かしていて、 かつ本番デプロイ元が main 以外のブランチになっているチーム。

症状

バグを直して PR を出し、CI も緑、本番ブランチにマージしてデプロイもした。 なのに毎晩のバッチだけ古い挙動のまま。ログを見ても新しいコードが動いた形跡がない。 「デプロイが反映されていないのでは」と本番を何度も再デプロイして時間を溶かす。

原因（仕様であってバグではない）

GitHub Actions の on: schedule は、常にリポジトリのデフォルトブランチのワークフロー定義で起動する。 さらに actions/checkout@v4 を ref: 無しで書くと、そのデフォルトブランチをチェックアウトする。

つまり実行されるスクリプトの実体は「デフォルトブランチ版」。 本番デプロイ元が別ブランチ（例: release、prod、cost-opt など）だと、同じファイルの中身が2つ存在し、 アプリは片方、定期バッチはもう片方を使うという状態になる。

ブランチが長く分岐しているほど中身の差は開く。実測例では、片方だけに167コミット・もう片方だけに201コミットあり、 問題のスクリプトはデフォルトブランチ側の方が新しかった（＝本番デプロイ元の方が古い）。 この状態で「本番ブランチを土台に」直すと、古い版への変更を作ったうえに定期バッチには一切効かないという二重の空振りになる。

検出手順

1. 定期実行がどのブランチで走っているかを確認する

gh run list --workflow=<ワークフロー名>.yml --limit 3 \
  --json headBranch,status,conclusion,createdAt,databaseId \
  -q '.[] | "\(.createdAt) \(.headBranch) \(.status)/\(.conclusion) id=\(.databaseId)"'

headBranch がデフォルトブランチになっていれば、この罠の条件を満たす。

2. デフォルトブランチと本番デプロイ元を確認する

gh repo view --json defaultBranchRef -q .defaultBranchRef.name

3. 触ろうとしているファイルが2ブランチで食い違っていないか調べる（着手前に必ず）

# 分岐の大きさ
git rev-list --count origin/<デフォルト>..origin/<デプロイ元>
git rev-list --count origin/<デプロイ元>..origin/<デフォルト>

# そのファイルの最終更新がどちらが新しいか
git log -1 --format="%ad %h %s" --date=short origin/<デフォルト>   -- <パス>
git log -1 --format="%ad %h %s" --date=short origin/<デプロイ元>  -- <パス>

# 中身の差
git diff origin/<デフォルト> origin/<デプロイ元> -- <パス> --stat

4. そもそもその列/機能に触っているのはどちらの版かを確かめる

git grep -n "<関数名や列名>" origin/<デフォルト>  -- scripts src
git grep -n "<関数名や列名>" origin/<デプロイ元> -- scripts src

片方で 0 件なら、その処理は片方のブランチにしか存在しない。 「本番で動いているはず」という思い込みが、ここで崩れる。

対処のルール（これだけ覚える）

触るもの	base にすべきブランチ
.github/workflows/ 配下	デフォルトブランチ
定期バッチが実行するスクリプト（scripts/ 等）	デフォルトブランチ
Web アプリ本体・API・アプリ内 cron ハンドラ	本番デプロイ元ブランチ

着手前に「このファイルは誰が実行するのか」を1回だけ問う。schedule から実行されるなら base はデフォルトブランチ。

直ったことの確かめ方（デプロイ完了は証拠にならない）

新コードにしか存在しないログ行を1本仕込み、実行ログにそれが出たことを確認する。

console.log(`結果: 更新=${updated}, 無効化=${deactivated}, <新機能名>: ${newCount}件`);

gh run view <run-id> --log | grep -iE "<新機能名>|結果:"

この行が出ていれば、その実行が新コードだったと断定できる。 「マージした」「デプロイした」「CI が緑だった」はいずれも “定期実行が新コードを使った”ことの証拠にならない。

応用: 逆方向の事故を先に防ぐ

片方のブランチにしかない「上書き処理」がある場合、将来ブランチを揃えた瞬間にそれが有効化される。 例えば「DB の値をシートの値で無条件に上書きする同期」がデプロイ元ブランチにだけ存在するなら、 デフォルトブランチへ寄せた瞬間に手で直したデータが元に戻る。 ブランチを統合する前に、git diff で上書き系の処理が増えないかを必ず見る。

根本対処

• 本番デプロイ元をデフォルトブランチに一致させる（最善）
• できないなら、ワークフローに ref: を明示して意図を固定する

  - uses: actions/checkout@v4
    with:
      ref: <本番ブランチ>
  

  この1行があるだけで、読む人が「どちらの版が動くのか」で迷わなくなる