merge-main-flow

name	merge-main-flow
description	This skill should be used when the user asks to 'origin/mainをmergeしてpushして', 'mainを取り込んでCI確認して', 'merge main and push', 'update this branch from main', or wants a one-command style flow that fetches origin/main, merges it into the current branch, resolves conflicts, pushes, and checks CI.
tools	["Bash(git *)","Bash(gh pr *)","Bash(gh run *)","Bash(bun *)","Bash(pnpm *)","Read","Edit","Write","Glob","Grep","TodoWrite"]

Merge Main Flow

現在ブランチに origin/main を merge し、conflict 解消、push、CI 確認までを 1 つの連続した作業として完了する。

pr-watch-auto との差分:

• merge-main-flow は branch 更新の単発フロー。origin/main を取り込み、push 後の CI 初期確認まで行う。
• pr-watch-auto は PR push 後の長い監視ループ。CI failure 修正、再 push、merge 完了待機まで続ける。
• watch-pr / ci-watcher は監視中心。merge-main-flow は実際に git merge origin/main を実行して branch を更新する。

基本方針

rebase ではなく merge を使う。merge commit が残ることで、いつ main を取り込んだか、どの conflict をどう解消したかを履歴から追跡できる。

作業前に現在ブランチと作業ツリーを確認する。未コミット変更がある場合は、変更内容が今回の conflict 解消に必要かを確認し、原則としてそのまま混ぜない。既存のユーザー変更を勝手に revert しない。

全体フロー

function merge_main_flow():
  assert_on_feature_branch()
  inspect_worktree()

  run("git fetch origin main")
  merge_result = run("git merge origin/main")

  if merge_result has conflicts:
    resolve_conflicts()
    run_targeted_verification()
    run("git add <resolved files>")
    run("git merge --continue")

  run_post_merge_verification()
  run("git push")
  check_ci_after_push()
  report_result()

Step 1: git fetch origin main

git fetch origin main

fetch 後に必要なら差分を確認する。

git log --oneline --decorate --graph HEAD..origin/main

origin/main に新規 commit がなければ、merge は no-op になる可能性がある。その場合でも push 前に作業ツリーと PR 状態を確認する。

Step 2: git merge origin/main

git merge origin/main

merge が clean に終わった場合は、生成された merge commit または no-op 状態を確認する。

git status --short --branch
git log --oneline --decorate -5

Step 3: conflict 解消

Conflict が出たら、CI を待たずに解消する。GitHub Actions の pull_request workflow は conflict がある PR では実行されないことがあるため、conflict 解消が最優先。

git status --short
git diff --name-only --diff-filter=U

各 conflict file で以下を行う。

1. HEAD 側が現在ブランチの意図、origin/main 側が main の新しい状態であることを確認する。
2. 片側を丸ごと採用せず、両方の意味を統合する。
3. generated file、lock file、snapshot など丸ごと採用が妥当な file では、採用理由を確認してから --ours / --theirs を使う。
4. 解消後に conflict marker が残っていないことを確認する。

git diff --check
rg -n '^(<<<<<<<|=======|>>>>>>>)' .

解消できたら merge を続行する。

git add <resolved-files>
git merge --continue

git merge --continue が editor を開く環境では、既定の merge message を使う。message を編集する場合は日本語で、何を取り込んだかを短く書く。

Step 4: push 前確認

push 前に最低限の local verification を実行する。repo 固有のコマンドが分かる場合はその package の check を優先し、不明な場合は変更範囲に近い check を選ぶ。

function run_post_merge_verification():
  if package has known check command:
    run(package_check)
  else if root has lightweight check:
    run(root_check)
  else:
    run("git diff --check")

検証が失敗したら、merge 解消のミスか main 取り込みによる契約変更を調査し、修正してから再実行する。検証を飛ばして push しない。

Step 5: push

git push

push が rejected されたら、リモートに新しい commit が増えている。再度 fetch し、rebase ではなく merge で統合する。

function handle_push_reject():
  run("git fetch origin")
  run("git merge @{u}")
  if conflicts:
    resolve_conflicts()
    run("git merge --continue")
  run("git push")

Step 6: CI 確認

PR がある場合は、まず conflict 状態を確認する。

gh pr view --json number,url,mergeable,mergeStateStatus,state

mergeStateStatus が DIRTY / dirty なら、CI より前に conflict 解消へ戻る。問題なければ checks を見る。

PROHIBIT: gh pr checks --watch — CI 完了を待つ間に PR の behind/conflict 状態変化を検出できないため。代わりに以下のポーリングを使う。

function check_ci_after_push(pr_number):
  loop every 30-60 seconds:
    merge_state = gh pr view {pr_number} --json mergeable,mergeStateStatus
    if merge_state.mergeStateStatus in ["DIRTY", "BEHIND"]:
      report("PR state changed to " + merge_state.mergeStateStatus + " during CI")
      return merge_state

    checks = gh pr checks {pr_number}
    if all required checks passed:
      return {status: "passed"}
    if any required check failed:
      return {status: "failed", checks: checks}
    // else: pending, continue

PR がまだない場合は、直近の workflow run を確認する。

gh run list --limit 5

CI failure が出た場合は、失敗 check と log link を報告し、必要なら pr-watch-auto の failure 調査フローに引き継ぐ。

完了条件

以下を満たしたら完了とする。

• origin/main の取り込みが完了している。
• conflict marker が残っていない。
• merge commit または no-op の状態が確認できている。
• push が成功している。
• PR conflict 状態と CI の初期結果を確認している。

最後に、PR URL、merge した main commit 範囲、conflict の有無、実行した verification、CI の結果を短く報告する。

Bundled Resources

(No bundled resources found)