章: 第7章: チーム運用を安定させる設計

コミット履歴だけでは「公開した版」が見えにくい

Gitにはコミット履歴がありますが、それだけでは「どの時点をリリースしたのか」が一目でわからないことがあります。

特に実務では、

• いつ本番へ出したのか
• どの版で不具合が起きたのか
• どの状態へ戻せばよいのか

を追える必要があります。

そこで役立つのがタグです。

タグは、特定のコミットに対して「この時点がリリース版です」と印をつける仕組みです。

タグがあると何が良いか

たとえば v1.2.0 のようなタグを打っておけば、あとからその時点の状態をすぐ参照できます。

git tag v1.2.0

これにより、

• リリース単位で履歴を追える
• 障害時に対象バージョンを特定しやすい
• 過去版を基準に比較しやすい

といった利点があります。

リリースとは何か

実務でのリリースは、単にコードがマージされたという話ではありません。

• この版を公開した
• この版を利用者へ届けた
• この版に意味のある変更が含まれている

という区切りを持つことが多いです。

そのため、タグは単なる目印ではなく、運用上の節目を記録するための印 として使われます。

実務での使い方

よくある流れは次のようなものです。

1. リリース対象コミットを確定する

2. タグを打つ

3. 必要に応じて GitHub などで Release 情報を作る

GitHub の Release は、タグに説明文や配布物の情報を紐づけて見やすくしたものだと考えると理解しやすいです。

どんな名前をつけるか

タグ名はチームルール次第ですが、よくあるのは次のような形式です。

• v1.0.0
• v1.2.3
• release-2026-05-06

大事なのは、あとから見て意味がわかることです。命名規則が揃っていると、運用時の混乱がかなり減ります。

実務で意識したいこと

• リリースした時点を明確に残す
• どのタグが本番反映済みかを把握する
• 変更内容とタグを結びつけて管理する
• 障害時に「どの版か」を素早く特定できるようにする

タグとリリースは地味に見えますが、運用が長くなるほど効いてきます。

よくある失敗

• タグを打っていないので公開版が追えない
• 命名がバラバラで分かりにくい
• リリースノートがなく、何が入った版かわからない

コードを書く力とは別に、「公開した版を追える状態にする力」も実務では重要です。

チェックポイント: タグは単なる飾りではなく、「この版を出した」と後から説明できるようにするための運用資産です。

まとめ

• タグは特定コミットにリリースの印をつける仕組み
• どの版を公開したかを追いやすくなる
• GitHub Release はタグに説明を載せて整理したものと考えられる
• 命名規則と運用ルールを揃えることが重要
• 長期運用ではタグとリリース管理が効いてくる

ここまでで、Gitシリーズは基礎操作からチーム開発、履歴整理、調査、リリース運用まで一通りそろいました。さらに広げるなら、GitHub Actions 連携、保護ブランチ設定、レビュー運用ルールの設計あたりが自然な次のテーマです。

The post 第23回: タグとリリースの基本 — 「いつの版を出したのか」を明確に残す first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第7章: チーム運用を安定させる設計

ブランチは切ればよいのではなく、運用ルールまで含めて設計する

ブランチの基本操作はすでに見てきました。しかし実務では、「ブランチを作れる」だけでは足りません。

問題になるのは、

• どのブランチを本流とするか
• どこから作業ブランチを切るか
• いつマージするか
• リリースや保守をどう分けるか

といった運用方針です。

この方針全体を考えるのが、ブランチ戦略です。

なぜ必要なのか

チームごとに好き勝手にブランチを切り始めると、次のような問題が起きます。

• どれが本番に近いブランチかわからない
• どこへ向けたプルリクエストか迷う
• 緊急修正の反映先が混乱する
• リリース管理が人依存になる

つまりブランチ戦略は、Gitの技術論というより、チームの交通整理 です。

よくある考え方

小規模なチームでは、次のようなシンプルな形がよくあります。

• main: 常に安定状態
• feature/*: 機能開発用
• 必要に応じて hotfix/*: 緊急修正用

この程度でも、何も決めていない状態よりずっと運用しやすくなります。

一方で、リリース単位や保守期間が明確なプロダクトでは、リリース用ブランチを設けることもあります。

大事なのは複雑さより一貫性

ブランチ戦略を考えると、つい高度なモデルを真似したくなります。しかし実務では、複雑な戦略を導入すること自体が正解ではありません。

重要なのは、

• チーム全員が理解できる
• 日常運用で迷わない
• リリースや保守の流れに合っている

ことです。

つまり、立派そうな戦略より、自分たちの開発速度に合った単純で守れるルール の方が強いです。

実務で意識したい観点

この4つが整理されていると、ブランチ運用はかなり安定します。

よくある失敗

• 戦略だけ立派で、誰も守れない
• ブランチの意味が曖昧
• 緊急修正の流れが決まっていない
• 小規模なのに必要以上に複雑な運用にする

ブランチ戦略は設計ですが、同時に運用でもあります。守れない戦略はないのと同じです。

チェックポイント: 良いブランチ戦略は「高度なもの」ではなく「迷わず運用できるもの」です。

まとめ & 次のステップ

• ブランチ戦略はブランチの切り方だけでなく運用ルール全体を指す
• 目的はチームの交通整理と安定運用
• 小さなチームではシンプルな戦略の方が機能しやすい
• 大事なのは複雑さより一貫性と実行可能性
• 本番・開発・緊急対応の流れを整理しておくと強い

次回はタグとリリースを扱います。 どの時点を「公開した版」として記録するのかは、運用の最後の整理として重要です。

The post 第22回: ブランチ戦略の基本 — チーム開発で「どう分けるか」を決めておく意味 first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第7章: チーム運用を安定させる設計

コンフリクトそのものより、慌てた解消の方が危ない

Gitでよく怖がられるのがコンフリクトです。確かに画面に見慣れない印が出るので、最初は身構えやすいです。

しかし実務で本当に危ないのは、コンフリクトが起きること自体ではありません。

コンフリクトを急いで雑に解消して、本来残すべき変更を消してしまうことの方が危険です。

そのため大事なのは、「コンフリクトは異常事態」ではなく「人間の判断が必要な状態」と理解することです。

どんなときに起きるのか

コンフリクトは、同じ箇所や近い箇所を別のブランチで変更していたときに起きやすいです。

• 同じ関数の同じ行を両方で修正した
• 片方で削除し、片方で追加した
• 並び順や構造を互いに変えていた

つまりGitが悪いのではなく、どちらを採用すべきか自動判断できない から止まっているだけです。

実際に見るべきもの

コンフリクト時には典型的に次のような印が入ります。

<<<<<<< HEAD
現在のブランチ側の内容
=======
取り込みたい側の内容
>>>>>>> feature/login-validation

ここでやることは単純です。

• 現在側の意図を読む
• 相手側の意図を読む
• どちらを残すか、どう統合するか決める

大事なのは、印を消すことではなく、最終的に正しいコードを残すこと です。

実務での解消手順

1. どのファイルで衝突しているか確認する

2. その変更が何のためのものか把握する

3. 片方だけ採用するのか、両方を統合するのか決める

4. テストや動作確認を行う

5. 問題なければ解消済みとして進める

特に3番が重要です。機械的に「上を残す」「下を残す」ではなく、意図を読む必要があります。

実務でよくある失敗

• コンフリクト印だけ消して内容を読んでいない
• 片方の修正を丸ごと落としてしまう
• 解消後に動作確認しない
• なぜ衝突したかを振り返らない

コンフリクト解消は編集作業であると同時に、仕様理解やコード理解の確認作業でもあります。

強い人の考え方

コンフリクトに強い人は、Gitの操作が速い人というより、コードの意味を落ち着いて読める人です。

チェックポイント: コンフリクト解消のゴールは「印を消すこと」ではなく「正しい最終状態を作ること」です。

まとめ & 次のステップ

• コンフリクトはGitが自動判断できない状態
• 危ないのは発生そのものではなく、雑な解消
• 片方を選ぶか、両方を統合するかは意図で判断する
• 解消後は必ずテストや動作確認を行う
• コンフリクト対応はコード理解力が問われる場面でもある

次回はブランチ戦略の基本を扱います。 コンフリクトを減らし、チーム運用を安定させるには、そもそものブランチの切り方も重要です。

The post 第21回: コンフリクト解消の実践 — 「怖いイベント」ではなく「判断が必要な状態」と捉える first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第6章: 現場で差がつく補助操作

不具合調査でつらいのは「原因が多すぎる」こと

実務でよくあるのが、「いつから壊れたのかわからない」という状況です。

• 1週間前は動いていた
• その間に何十コミットも入っている
• どの変更が原因か見当がつかない

このとき、最新から順番に全部読むのはかなり大変です。

そこで使えるのが bisect です。

bisect は、正常な地点と異常な地点の間を二分探索して、原因コミットを絞り込むための機能です。

どういう考え方か

やることはシンプルです。

• 今は壊れているとわかっている地点を bad
• 以前は正常だったとわかっている地点を good

として、その間のコミットを半分ずつ試していきます。

git bisect start
git bisect bad
git bisect good <正常だったコミットID>

すると Git が候補を1つずつ示してくれるので、その時点で動くか壊れるかを判定して進めます。

なぜ強いのか

10件、20件ならまだしも、100件近い変更の中から原因を探すのは人力だとかなり厳しいです。

bisect を使うと、総当たりではなく半分ずつ候補を削れるので、かなり効率よく絞れます。

つまり bisect の価値は、Gitコマンドを増やすことではなく、調査コストを一気に下げること にあります。

実務で使う場面

• 不具合がいつ混入したか特定したいとき
• 再現条件が明確で、正常/異常を判定できるとき
• 変更量が多く、人力で履歴を追うのが重いとき

特に「テストを回せば壊れているか分かる」状態だと、bisect はかなり強力です。

使う前に必要なこと

bisect は万能ではありません。少なくとも次が必要です。

• 何をもって正常/異常とするか決まっている
• あるコミットをチェックしたときに判定できる

ここが曖昧だと、探索の精度が落ちます。

つまり bisect は「Gitの魔法」ではなく、再現できる不具合調査を効率化する手段です。

実務での位置づけ

原因の見当があるなら log や show で十分なこともあります。ただ、候補が広すぎるときの bisect はかなり頼りになります。

チェックポイント: bisect は「壊れた理由を自動で教える」機能ではなく、「怪しいコミットを効率よく絞り込む」機能です。

まとめ & 次のステップ

• bisect は正常地点と異常地点の間を二分探索で絞る機能
• 不具合混入コミットの特定に強い
• 正常/異常を判定できることが前提になる
• 候補が多いときほど効果が大きい
• Gitは履歴管理だけでなく調査の道具としても強力

次回はコンフリクト解消の実践を扱います。 コンフリクトは避けるだけでなく、起きたときにどう落ち着いて処理するかが実務では重要です。

The post 第20回: bisectの基本 — 「いつ壊れたのか」を二分探索で突き止める first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第6章: 現場で差がつく補助操作

作業中なのに、急に別件へ切り替えたいことがある

実務では、今触っている作業を最後まで終えてから次に進めるとは限りません。

• レビュー修正が急に来る
• 緊急バグ対応を先にやる必要が出る
• 別ブランチへすぐ切り替えたい

このとき困るのが、「まだコミットしたくない途中変更」が作業ツリーに残っている状態です。

そこで使うのが stash です。

stash は、作業中の変更をいったん退避して、作業ツリーを一時的にきれいな状態へ戻すための仕組みです。

どういうとき便利か

たとえば機能追加の途中で、まだ中途半端な変更があるとします。しかし今すぐ main に戻って別件対応したい。

そういうときに、

git stash

としておけば、作業中の変更を一時退避できます。

あとで戻したいときは、たとえば次のようにします。

git stash pop

これで、退避していた変更を作業ツリーへ戻せます。

なぜコミットではだめなのか

もちろん「途中でもコミットすればよい」と考えることもできます。これは場面によっては正しいです。

ただし、

• まだ意味のある単位になっていない
• 履歴に残したくない途中状態
• 一時的に逃がしたいだけ

というケースでは、無理にコミットすると履歴がノイズだらけになります。

そのため、stash は「履歴へ残すほどではない途中作業」の避難場所として便利です。

実務でよくある使いどころ

• 作業途中で別ブランチへ切り替えたいとき
• Pull する前に未整理変更を一時退避したいとき
• 緊急対応を先に進める必要があるとき

一言でいえば、stash は「今の作業を捨てずに保留する」ための機能です。

注意点

便利だからといって、stash を長く溜め込みすぎると何を退避したのかわからなくなります。

また、戻すときに現在の変更と衝突することもあります。

つまり stash は便利な一時置き場ですが、長期保管庫ではありません。

実務では「すぐ戻す前提」で使う方が安全です。

チェックポイント: stash はコミットの代わりではなく、一時退避のための仕組みです。履歴を汚さずに作業を切り替えるために使います。

まとめ & 次のステップ

• stash は作業中の変更を一時退避する仕組み
• コミットしたくない途中状態を避難させたいときに便利
• 緊急対応やブランチ切り替えで役立つ
• 長く溜め込みすぎると管理しづらくなる
• 一時置き場として短期的に使うのが実務では安全

次回は bisect を扱います。 「いつ壊れたのか」を効率よく絞り込む調査手順として、かなり実務的な価値があります。

The post 第19回: stashの基本と使いどころ — コミットしたくない途中作業をいったん脇に置く first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第6章: 現場で差がつく補助操作

ブランチ全体ではなく、特定のコミットだけ欲しいことがある

Gitでは通常、別ブランチの変更を取り込むときに merge や rebase を使います。これはブランチ全体の流れを前提にした操作です。

しかし実務では、ときどきこういう場面があります。

• バグ修正コミットだけを本番向けブランチへ入れたい
• 先に別ブランチで直した1件だけを流用したい
• 他の変更はまだ取り込みたくない

このときに使うのが cherry-pick です。

cherry-pick は、別の場所にある特定コミットだけを選んで現在のブランチへ取り込む操作です。

何が便利なのか

たとえば feature/a ブランチに、

• まだ途中の機能追加
• ただし1件だけ緊急バグ修正

が混ざっていたとします。

このとき、ブランチごと merge すると未完成機能まで入ってしまいます。

ですが cherry-pick なら、必要な修正コミットだけを選んで持ってこられます。

git switch main
git cherry-pick <コミットID>

これで、そのコミットの内容だけが現在のブランチへ反映されます。

どんな場面で使われるか

• 緊急修正だけをリリースブランチへ反映したいとき
• 他ブランチの有用な小修正を流用したいとき
• 複数ブランチ運用で、同じ修正を選択的に反映したいとき

特に本番運用や保守フェーズでは、「全部は入れたくないが、この1件だけ必要」という状況が起こりやすいです。

注意したい点

cherry-pick は便利ですが、安易に多用すると「同じ修正が複数ブランチにどう入ったか」が追いづらくなることがあります。

そのため、

• 本当に1コミット単位で持ってきたいのか
• いずれ通常の merge や rebase で統合される予定があるのか

を考えて使う必要があります。

また、適用先でコンフリクトすることも普通にあります。便利な近道ですが、自動で全部きれいに済むわけではありません。

実務での考え方

cherry-pick は万能な統合手段ではなく、必要な変更をピンポイントで動かすための道具です。

チェックポイント: cherry-pick は「ブランチを取り込む」のではなく「コミットを選んで取り込む」操作です。この粒度の違いを意識しましょう。

まとめ & 次のステップ

• cherry-pick は特定コミットだけを現在ブランチへ取り込む操作
• 緊急修正や小さな流用で役立つ
• ブランチ全体を統合したい場面には向かない
• 便利だが多用すると履歴追跡が複雑になりやすい
• コミット単位で必要な変更を動かす道具として使うとよい

次回は stash を扱います。 作業途中の変更をいったん退避したい場面は、実務ではかなり頻繁にあります。

The post 第18回: cherry-pickの基本 — 別ブランチの変更を「必要なものだけ」持ってくる first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第5章: 変更履歴を実務で整える

実務で本当に怖いのは「間違えた変更」より「取り消し方を間違えること」

開発では、マージした変更をあとから取り消したくなることがあります。

• バグを入れてしまった
• 仕様理解がずれていた
• 本番で問題が出たので戻したい

このとき初心者が混同しやすいのが、reset と revert です。

実務では、共有済みの履歴を安全に取り消したい場面で revert がよく使われます。

理由は、履歴そのものを消すのではなく、「打ち消す変更を新しく追加する」からです。

revert は何をしているのか

たとえば、あるコミットでログイン機能を壊してしまったとします。

revert を使うと、そのコミットをなかったことにするのではなく、その変更を打ち消すための新しいコミット を作ります。

git revert <コミットID>

これにより、履歴は残したまま、安全に「取り消した」という事実も追えるようになります。

なぜ実務で好まれるのか

チーム開発や本番運用では、すでに共有された履歴を書き換えるのはリスクがあります。

そこで revert を使えば、

• 履歴の整合性を壊しにくい
• 何を取り消したかが明確に残る
• 他のメンバーとの認識ズレを起こしにくい

という利点があります。

つまり revert は、「なかったことにする」より「安全に打ち消す」を重視した操作です。

reset とどう違うか

個人のローカル作業なら reset が便利なこともありますが、共有済み変更の取り消しでは revert の方が実務向きです。

どんな場面で使うか

• マージ後に不具合が見つかったとき
• 本番反映した変更を一時的に戻したいとき
• 共有済み履歴を壊さずに修正したいとき

特に本番障害の初動では、「原因を完全に直す」より先に、「問題のある変更を安全に戻す」判断が重要になることがあります。

実務で意識したいこと

• 何を取り消すのかを正確に確認する
• 1コミットだけでよいのか、関連変更も必要かを考える
• revert したあとにテストや確認を行う
• 取り消した事実をチームへ共有する

「戻せたから終わり」ではなく、「安全に戻して状況を安定させる」までが実務です。

チェックポイント: 実務での revert は「履歴を消す」操作ではなく、「共有済み変更を安全に打ち消す」操作です。

まとめ & 次のステップ

• revert は変更を打ち消す新しいコミットを作る
• 共有済み履歴を壊しにくいため、実務でよく使われる
• reset は位置を戻す、revert は安全に打ち消すという違いがある
• 本番やチーム開発では履歴の整合性が重要
• 取り消し後の確認と共有まで含めて運用することが大切

次回は cherry-pick を扱います。 別ブランチの変更を必要なものだけ選んで持ってくる場面は、実務では意外とよく出ます。

The post 第17回: revertの基本 — 本番で「安全に取り消す」ために履歴を壊さないという考え方 first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第5章: 変更履歴を実務で整える

作業中のコミット数と、本流に残したい履歴数は同じとは限らない

実務では、作業中に細かくコミットを積むことがあります。

• 途中保存のコミット
• レビュー指摘への小さな修正
• 一時的な調整コミット

これは作業中としては自然です。しかし、そのまま本流へ全部並べると、あとから履歴を読む人には少しノイズになります。

そこで使われるのが squash merge です。

squash merge は、複数のコミットを1つにまとめた形で本流へ取り込む方法です。

なぜ使うのか

プルリクエストの中では10コミットあったとしても、「本質的にはログインバリデーション追加」という1テーマなら、本流には1件として残したいことがあります。

そうすると履歴がかなり読みやすくなります。

つまり squash merge は、作業中の細かい履歴と、本流に残したい履歴を分けて考えるための方法です。

どういう場面に向いているか

• 1つのプルリクエストが1つの目的にきれいにまとまっているとき
• レビュー修正コミットが多く、本流へは要点だけ残したいとき
• 本流の履歴をできるだけ簡潔に保ちたいとき

たとえば次のようなコミットが並んでいたとしても、

• feat: ログイン時の入力チェック追加
• fix: レビュー指摘で命名修正
• fix: テストケース追加

本流では「ログイン時の入力チェック追加」として1件にまとめた方が読みやすい場合があります。

通常の merge との違い

ここで大事なのは、squash merge は「作業履歴を消す」というより、「本流に残す単位を整える」ことだと理解することです。

実務での考え方

チームによっては「PRは squash merge で統一」という運用も珍しくありません。

理由は単純で、

• main の履歴が読みやすい
• 1PR = 1コミットで意味が追いやすい
• レビュー修正の細かいノイズを本流へ残しすぎない

という利点があるからです。

ただし、細かな途中経過まで本流に残したい場合は通常 merge の方が向くこともあります。ここも運用次第です。

チェックポイント: squash merge は「コミットを減らす技術」ではなく、「本流に残す意味の単位を整える技術」と考えましょう。

まとめ & 次のステップ

• squash merge は複数コミットを1つにまとめて取り込む方法
• 作業中の履歴と本流に残したい履歴を分けて考えられる
• PR単位で履歴を簡潔に保ちたいときに向いている
• 本流の可読性を重視するチームでよく使われる
• merge 方法はチーム方針と履歴の残し方で選ぶ

次回は revert を扱います。 実務で「変更を取り消したい」ときに、なぜ reset ではなく revert が選ばれることが多いのかを整理します。

The post 第16回: squash mergeの基本 — 細かい作業履歴を「意味のある1件」にまとめて取り込む first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第5章: 変更履歴を実務で整える

merge と似て見えて、目的が少し違う

Gitの実務に少し慣れてくると、merge に加えて rebase という言葉をよく見かけます。

ここで混乱しやすいのは、「どちらもブランチをまとめる操作に見える」ことです。確かに結果として変更を統合する点は似ていますが、意図は同じではありません。

rebase は、変更を取り込むと同時に、履歴の並びを整えるために使われる操作です。

つまり実務では、「差分を入れる」だけでなく、「履歴を読みやすく保つ」ために使われることが多いです。

どんな場面で使うのか

たとえば、main が先に進んでいる間に、自分の作業ブランチでも数コミット進んでいたとします。

このままでは、自分のブランチは少し古い土台の上に乗っています。

そこで rebase を使うと、自分のコミットをいったん外して、最新の main の上に積み直すような形になります。

git fetch origin
git switch feature/login-validation
git rebase origin/main

こうすると、履歴が「最新の本流の続き」として並びやすくなります。

merge と rebase のざっくりした違い

merge は「起きたことをそのまま残す」感覚に近く、rebase は「読みやすい履歴に並べ直す」感覚に近いです。

どちらが絶対に正しいというより、チームの運用方針に合わせて使い分けます。

実務でありがちな使いどころ

• プルリクエスト前に履歴を整理したいとき
• 長く作業したブランチを最新 main に追従させたいとき
• マージコミットを増やしすぎず、履歴を読みやすく保ちたいとき

特にレビュー前のブランチ整理では、rebase によって差分が読みやすくなることがあります。

注意点

rebase は便利ですが、履歴を書き換える操作でもあります。ここが重要です。

そのため、すでに他人と共有している履歴に対して雑に使うと、履歴の認識がずれて混乱を招くことがあります。

初心者のうちはまず、

• 自分の作業ブランチで使う
• 公開済みブランチでは慎重に使う

という感覚を持っておくと安全です。

チェックポイント: rebase は「変更を取り込む」だけでなく「履歴を整える」操作。この視点を持つと意味が理解しやすくなります。

まとめ & 次のステップ

• rebase は履歴を整えながら変更を取り込む操作
• merge はそのまま統合、rebase は並びを整えて統合という違いがある
• 実務ではレビュー前や本流追従で使われやすい
• 便利だが履歴を書き換える操作なので慎重さが必要
• まずは自分の作業ブランチで使う前提で考えると安全

次回は squash merge を扱います。 複数コミットを1つにまとめて本流へ取り込む考え方を整理しましょう。

The post 第15回: rebaseの基本と使いどころ — 「履歴を整える」とは何を整えているのか first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.

章: 第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 の基本と使いどころを扱います。 履歴をきれいに整える操作が、なぜ実務で重視されるのかを見ていきましょう。

The post 第14回: フォーク運用の基本 — 書き込み権限がないリポジトリへどう貢献するのか first appeared on 未経験から実務レベルへ｜PHP初心者向け実践学習ブログ.