こんにちは、かつコーチです。
チーム内でのPull Requestに慣れてきたら、次に挑戦したいのが、社外のOSS（オープンソースソフトウェア）プロジェクトへの貢献です。
「自分にはまだ早いのでは」と感じる方も多いのですが、仕組みさえ理解すれば、タイポの修正のような小さな貢献からでも始められます。
この記事では、フォークを使ったOSS貢献の基本的な流れを解説します。
読み終える頃には、自分のリポジトリではないプロジェクトにも、安心して変更を提案できるようになります。
フォークとは？
フォーク＝他人の家を自分の敷地にコピーしてから改装案を提案する
フォーク（Fork）とは、他人が所有するリポジトリを、自分のGitHubアカウント配下に複製する機能です。
たとえるなら、フォークは「他人の家の設計図を、まるごと自分の敷地にコピーしてくる」ような操作だとイメージしてください。
OSSプロジェクトの多くは、外部の人が直接そのリポジトリに書き込む権限（push権限）を持っていません。
そこで、まず設計図（リポジトリ）を自分の敷地（自分のアカウント）にコピーしてきて、自分の敷地内で自由に改装（コードの変更）を行います。
改装が終わったら、元の持ち主に「このリフォーム案を、本物の家にも採用してもらえませんか」とPull Requestという形で提案する、という流れになります。
なぜフォークが必要なのか
もし誰でも自由に他人のリポジトリへ直接pushできてしまったら、意図しない変更が紛れ込んでしまう危険があります。
フォークという「自分の敷地にコピーしてから提案する」仕組みを挟むことで、元のプロジェクトの安全性を保ちながら、外部の誰もが貢献しやすい環境を実現しています。
OSS貢献の基本的な流れ
手順1：リポジトリをフォークする
貢献したいOSSプロジェクトのGitHubページを開き、右上の「Fork」ボタンを押すと、自分のアカウント配下に複製が作成されます。
手順2：フォークしたリポジトリをローカルにクローンする
自分のアカウント配下にできたフォーク先のリポジトリを、ローカルにクローンします。
git clone git@github.com:your-username/awesome-project.git
cd awesome-project
さらに、元のリポジトリ（upstream）も参照できるように登録しておきます。
git remote add upstream git@github.com:original-owner/awesome-project.git
git remote -v
これは、自分の敷地にコピーした設計図が、本家の設計図とどこがつながっているのかを、あらかじめメモしておくイメージです。
手順3：作業用ブランチを作り、変更する
mainブランチを直接編集せず、目的に応じたブランチを作成します。
git switch -c fix/typo-in-readme
READMEの誤字を修正するなど、小さな変更から着手すると、初めてのOSS貢献としてハードルが下がります。
手順4：変更をpushしてPull Requestを送る
変更をコミットし、自分のフォーク先リポジトリにpushします。
git add .
git commit -m "READMEの誤字を修正"
git push origin fix/typo-in-readme
GitHub上で自分のフォークのページを開くと、「Compare & pull request」ボタンが表示されるので、そこから本家（upstream）に向けてPull Requestを作成します。
つまずきやすい設定・注意点
Pull Requestの送り先を間違え、自分のフォーク先のmainブランチに向けて提案してしまうケースがあります。
本家プロジェクトへ提案したい場合は、base repositoryが元のプロジェクト側になっているかを、作成画面で必ず確認しましょう。
よくあるつまずきポイント・エラー対処
フォーク元が更新されて古い状態のまま提案してしまった話
私が実際に小さなOSSへ貢献しようとした際につまずいたのが、このケースでした。
❌ Before
数週間前にフォークしたリポジトリで作業を進めていたのですが、その間に本家（upstream）ではどんどん更新が進んでいました。
古い設計図をベースに改装案を作ってしまったため、いざPull Requestを送ろうとしたところ、大量のコンフリクトが発生してしまいました。
✅ After
upstreamの最新状態を、自分のフォーク先に取り込む手順を踏むようにしました。
git switch main
git fetch upstream
git merge upstream/main
git push origin main
その後、改めて作業用ブランチを最新のmainから切り直したところ、コンフリクトの少ないシンプルな提案として送ることができました。
git switch -c fix/typo-in-readme-v2
この経験から、OSSへ貢献する際は、作業を始める前に必ずupstreamの最新状態を自分のフォークへ取り込んでおく習慣が大切だと学びました。
応用・一歩先の使い方
Contributing Guideを必ず確認する
多くのOSSプロジェクトには、CONTRIBUTING.mdというファイルが用意されており、コーディング規約やPull Requestの書き方など、そのプロジェクト独自のルールが記載されています。
改装のルールを確認せずに勝手にリフォームを進めてしまうと、後から大きな手戻りが発生することがあります。
貢献を始める前に、必ず目を通しておきましょう。
Draft Pull Requestで方向性を先に確認する
大きな変更に取り組む場合は、いきなり完成形のPull Requestを送るのではなく、「Draft pull request」として早い段階で方向性を共有すると、後の手戻りを防ぎやすくなります。
gh pr create --draft --title "認証まわりのリファクタリング（作業中）" \
--body "方向性についてメンテナーの意見を伺いたいです"
まとめ
この記事のポイント
- フォークとは、他人のリポジトリを自分の敷地にコピーしてから改装案を提案する仕組み
- フォーク後は
upstreamを登録し、本家の最新状態を定期的に取り込むことが重要 - 作業前に
CONTRIBUTING.mdを確認し、プロジェクト独自のルールに従う - 小さな修正（誤字修正など）から始めると、初めてのOSS貢献のハードルが下がる
次に読むべき記事
OSSでの貢献方法がわかったら、次はチーム開発における効率的なブランチ運用ルールを見ていきましょう。
「Git Flow・GitHub Flowとは？ブランチ運用ルールの考え方」で、代表的な運用モデルを解説しています。