GitHubでリポジトリをForkするのはよくあることです——open sourceへの貢献、ライブラリのカスタマイズ、あるいは単に試験用のコピーを手元に置きたい場合など。問題が生じるのは、元のプロジェクト（upstream）が開発を続ける一方で、自分のForkが止まったままになるときです。
数ヶ月後には、upstreamに200件の新しいコミットが積み重なり、重要なバグ修正や新機能が追加されているのに、Forkは作成当初のコミットのまま止まっているという状況になりがちです。Pull Requestを開こうとすると、コンフリクトが山積みになり、CIは次々と失敗し、マージは悪夢のような作業になります。これは誰かのミスではなく、Gitの構造上の問題です——ForkとUpstreamは独立して発展し、自動的な接続手段はありません。
Forkが「時代遅れ」になる理由と、すぐにsyncすべきサイン
リポジトリをForkするたびに、GitHubはその時点での独立したコピーを作成します。UpstreamでPRがマージされ、hotfixがリリースされ、dependenciesが更新されても——それらはForkに自動的には反映されません。2つのブランチは並行して発展し、その差は日々広がっていきます。
すぐにsyncすべきサイン：
- GitHubに「This branch is X commits behind upstream/main」と表示されている
- upstreamがインターフェースやAPIを変更したためCIが失敗している
- upstreamにPRを開きたいがコンフリクトが多すぎる
- upstreamでパッチされたセキュリティアドバイザリがForkにまだ適用されていない
ForkをUpstreamと同期する3つの方法——実際の比較
方法1：GitHub UIの「Sync fork」ボタン
GitHubは2022年からWebインターフェース上に「Sync fork」ボタンを導入しました。Forkのページを開き、branchのステータス行を確認して、Sync fork→Update branchをクリックするだけです。完了。
シンプルで、ターミナルを開く必要もありません。ただし制限も明確で、コンフリクトがない場合にしかsyncできません。自分が編集したファイルをupstreamも変更していた場合、GitHub UIはお手上げとなり、手動での解決を迫られます。
方法2：Git CLIで手動同期
従来の方法で、完全なコントロールが可能です。初回は、upstreamのリモートを追加してfetchします：
# 初回：upstreamリモートを追加
git remote add upstream https://github.com/original-owner/original-repo.git
# upstreamの変更をfetch（まだmergeしない）
git fetch upstream
# upstreamをローカルbranchにmerge
git checkout main
git merge upstream/main
# Forkにpush
git push origin mainまたは、historyをすっきり保つためにmergeの代わりにrebaseを使う方法：
git fetch upstream
git checkout main
git rebase upstream/main
git push origin main --force-with-leaseここで重要な注意点：私は--forceの代わりに--force-with-leaseを使っています。以前、誤ったbranchへのforce pushで重要なコードを失ったことがあり、それ以来git push --forceには細心の注意を払っています。--force-with-leaseフラグは、リモートにローカルが知らない新しいコミットがある場合にpushを拒否するため、盲目的なforce pushよりはるかに安全です。
方法3：GitHub Actionsで自動化
Forkが長期的なものであり、毎週手動でsyncすることを覚えていたくない場合、GitHub Actionsが根本的な解決策となります。スケジュールで実行するworkflowを作成し、自動でupstreamをfetchしてmerge——あとは何もする必要がありません。
メリット・デメリット分析——どの方法が適切か？
| 基準 | GitHub UI | Git CLI | GitHub Actions |
|---|---|---|---|
| 使いやすさ | 非常に高い | 中程度 | 低い（初回セットアップ時） |
| コンフリクト処理 | なし | あり | あり（設定が必要） |
| 完全自動化 | なし | なし | あり |
| 適している場面 | 一時的なsync、変更が少ない場合 | コントロールが必要、コンフリクトがある場合 | 長期Fork、本番環境 |
実際の判断基準：Forkがコードを読んだり短期的な試験用途であれば→GitHub UIを使う。独自のカスタマイズを持つForkをメンテナンスしており各変更をコントロールしたい場合→rebaseを使ったCLI。Forkが本番環境で動作する実際のプロダクトであり常にupstreamに追随する必要がある場合→GitHub Actionsによる自動化。
GitHub ActionsでForkの自動同期を実装する
Forkに.github/workflows/sync-upstream.ymlファイルを作成します：
name: Sync Fork with Upstream
on:
schedule:
# 毎日UTC午前6時（JST午後1時）に実行
- cron: '0 6 * * *'
workflow_dispatch: # UIから手動実行を許可
jobs:
sync:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- name: Checkout fork
uses: actions/checkout@v4
with:
token: ${{ secrets.GITHUB_TOKEN }}
fetch-depth: 0
- name: Configure git
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
- name: Add upstream remote
run: |
git remote add upstream https://github.com/original-owner/original-repo.git
git fetch upstream
- name: Merge upstream into main
run: |
git checkout main
git merge upstream/main --no-edit
git push origin mainoriginal-owner/original-repoを実際のupstreamのURLに置き換えてください。workflowは毎日実行され、自動でupstreamをfetchしてmainにmergeします。upstreamに新しい変更がない場合、mergeステップは何もせずすぐに終了します。
sync時のコンフリクトをスマートに処理する
難しいケース：自分のForkでファイルAを編集したところ、upstreamも同じファイルAを変更していた場合です。GitHub ActionsはmergeステップでFailします。状況に応じた2つの戦略があります：
戦略1：upstreamを優先する（theirsでオーバーライド）
常にupstreamの最新バージョンを取得し、コンフリクトしたファイルの自分のカスタマイズ部分をオーバーライドすることを受け入れる場合：
git fetch upstream
git checkout main
git merge -X theirs upstream/main
git push origin main使う場面：Forkが別ファイルに小さな機能を追加しているだけで、upstreamのコアファイルを変更していない場合。
戦略2：専用branchとrebaseでカスタマイズを維持する
長期Forkで私が最もよく使うパターンです：mainをupstreamのクリーンなミラーとして保ち、すべてのカスタマイズは専用branch（my-fork、custom-featuresなど）に置きます。
# mainは常にupstreamと同期
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
# カスタマイズを最新のupstreamの上にrebase
git checkout my-custom-branch
git rebase main
# コンフリクトがある場合、1コミットずつ処理
# git add . && git rebase --continue （コンフリクト解決後）
# git rebase --abort （やり直したい場合）
git push origin my-custom-branch --force-with-lease「upstreamのコード」と「自分のコード」を明確に分離することで、長期的にコンフリクトが大幅に減ります。
sync失敗時にIssueを自動作成する
手動での対応が必要なコンフリクトが発生した際に通知を受け取るため、workflowにstepを追加します：
- name: Notify on failure
if: failure()
uses: actions/github-script@v7
with:
script: |
github.rest.issues.create({
owner: context.repo.owner,
repo: context.repo.repo,
title: 'Sync upstream failed — manual intervention needed',
body: 'Sync upstreamワークフローが失敗しました。手動でコンフリクトを解決する必要があります。\n\nRun ID: ${{ github.run_id }}'
})workflowが失敗すると、run logへのリンクが含まれたIssueがリポジトリに自動作成されます。毎日Actionsタブを確認する必要はありません。
状態確認コマンドと実践的な注意点
sync前に、Forkがどのくらい遅れているか確認します：
# Forkがupstreamにbehindのコミット数
git fetch upstream
git rev-list --count HEAD..upstream/main
# ForkにまだないUpstreamのコミット一覧
git log HEAD..upstream/main --oneline
# Upstreamで変更されたファイル
git diff HEAD..upstream/main --name-only長期Forkで作業する際に覚えておきたいポイント：
- mainに直接コミットしない——Forkにカスタマイズがある場合、syncのたびにコンフリクトが起きやすい
- こまめにsyncする（少なくとも週1回）——差分が少ないうちに同期するほうが、3ヶ月分をまとめてsyncするより楽
- upstreamのCHANGELOGを読む——メジャーバージョンをmergeする前に、breaking changesは本番環境に適用する前に十分テストが必要
- 大きなsyncの前にversionをタグ付けする——何か問題が起きたときに明確なrollbackポイントを持つ：
git tag v1.2.3-before-sync
Upstreamの自動syncは完全な「セットアンドフォーゲット」ではありません——workflowが失敗した際の通知を確認し、ときに手動でコンフリクトを解決する必要があります。しかし、syncを放置して毎月2時間かけてコンフリクトの山を解消するよりも、1回あたり10分で済み、Forkは常に利用可能な状態を保てます。
