章: 第4章: チーム開発の実務フロー
フォークは「自分用の複製リポジトリ」を持つ仕組み
チームやOSSの開発では、元のリポジトリに直接書き込めないことがあります。
そのときに使うのがフォークです。
フォークは、他人のリポジトリを自分のアカウント配下へ複製して、そこで作業できるようにする仕組みです。
つまり、直接本家に触れない場合の作業場所を用意するのがフォークの役割です。
フォーク運用の基本イメージ
流れはおおむね次のようになります。
1. 本家リポジトリをフォークする
2. 自分のフォークを clone する
3. 作業ブランチを切る
4. 変更をコミットして自分のフォークへ push する
5. 自分のフォークから本家へプルリクエストを出す
この流れでは、変更はまず自分の管理下にあるフォークへ送られます。そのうえで、本家に取り込みを依頼します。
origin と upstream
フォーク運用では、リモートが2つ登場することが多いです。
origin: 自分のフォークupstream: 本家リポジトリ
この区別がかなり重要です。
git remote -v
を見たときに、どちらへ push し、どちらから最新を取り込むのかを把握しておく必要があります。
よくある運用
たとえば本家の最新へ追従したいときは、upstream から取り込みます。
git fetch upstream
git switch main
git merge upstream/main
一方、自分の変更を送る相手は通常 origin です。
git push origin feature/fix-typo
このように、取得先と送信先が分かれる のがフォーク運用の特徴です。
どんな場面で使われるか
- OSSへのコントリビュート
- 外部パートナーが本家へ直接 push できない場合
- 組織ポリシー上、本流への直接書き込みを制限している場合
実務では社内開発より OSS で見かけることが多いですが、「権限がない場所へ安全に変更提案する」という考え方は汎用的です。
初心者が混乱しやすい点
originとupstreamの役割が混ざる- 本家へ直接
pushしようとして失敗する - 本家の最新取り込みを怠って差分が古くなる
フォーク運用は少し複雑に見えますが、本質はシンプルです。
- 作業は自分の複製で行う
- 反映したい相手は本家
この2点を押さえるだけで整理しやすくなります。
チェックポイント: フォーク運用では、
originは自分、upstreamは本家。この対応を頭に固定しておきましょう。
まとめ & 次のステップ
- フォークは他人のリポジトリを自分管理下へ複製する仕組み
- 書き込み権限がない本家へ変更提案するときによく使う
originは自分のフォーク、upstreamは本家として使い分けるpush先と最新取り込み元が異なるのがポイント- フォークも結局は「安全に変更を提案するための運用」だと考えると理解しやすい
次回は rebase の基本と使いどころを扱います。 履歴をきれいに整える操作が、なぜ実務で重視されるのかを見ていきましょう。
