「教わったとおりにコミットしたのに、GitHubで見ると古い内容のまま。何か間違えたのかな？」
GitHubを使い始めたばかりだと、ボタンを押せても、その操作で何が起きたのかは分かりにくいですよね。
まず知っておきたいのは、自分のPCで開いているファイルと、GitHubで見ているファイルは、同じファイルを直接開いているわけではないということです。PC側で直しただけでは、GitHub側の内容は変わりません。
この記事では、ファイルを直してからGitHubに届くまでを、ひとつの例で説明します。Gitやコミットという言葉をまだ説明できなくても、読み進められる内容です。
💡 このページでわかること
- コミットすると何が起きて、何がまだ終わっていないのか
- GitHubに変更を届けるには何が必要なのか
- 送ったはずなのに、古い内容が見えるのはなぜか
PCで直した内容は、そのままGitHubには届かない
たとえば、プロジェクトの説明が書かれたファイルを、PCで開いたとします。そこにある「学習用のアプリです」という文章を、「初心者向けの学習用アプリです」に直して保存しました。
この時点で変わったのは、自分のPCにあるファイルです。GitHubのページで同じ名前のファイルを開いても、まだ「学習用のアプリです」と表示されることがあります。
GitHubは、ファイルや変更の記録をインターネット上で共有するサービスです。PCのファイルを編集する画面そのものではありません。変更を共有するには、PC側からGitHub側へ届ける必要があります。
「PCでは新しい文章なのに、GitHubでは古い文章」という違いは、この2か所の内容がまだそろっていないために起こります。
コミットすると、何が起きるの？
PCで行った変更を記録し、あとから「どこを変えたか」を確認できるようにする道具がGitです。名前は似ていますが、Gitは変更を記録・管理する道具、GitHubはそのファイルや記録を共有するサービスです。
Gitで「今回の変更を記録として残す」という操作が、コミットです。
先ほどの例なら、「紹介文に『初心者向け』を加えた」という変更を、PC側のGitの記録に残します。ファイルを保存するだけでなく、どんな変更をしたかをあとからたどれるようになるわけです。
ただし、コミットに入るのは、記録する対象として選んだ変更です。編集した内容すべてが、自動的に含まれるとは限りません。
自分のPCでコミットが完了したということは、PC側に記録を残せたということ。GitHubへ送れた、という意味ではありません。
そのため、「コミットは成功したのに、GitHubの文章は古いまま」という状態は起こりえます。必ずしも操作を間違えたわけではありません。
GitHubへ送る操作が「プッシュ」
PCに残した変更の記録を、GitHubなどの共有先へ送る操作をプッシュと呼びます。Git公式のプッシュ解説
先ほどの紹介文で考えると、操作の違いは次のようになります。
| 操作 | この例で起きること |
|---|---|
| 保存 | PCのファイルが「初心者向けの学習用アプリです」に変わる |
| コミット | 選んだ紹介文の変更が、PC側のGitの記録に残る |
| プッシュ | その記録を共有先へ送り、送った先でも修正を確認できるようにする |
つまり、「コミットしたのにGitHubへ反映されない」のは、記録する操作まで終わっていて、送る操作がまだ終わっていないからかもしれません。
使っているアプリによっては、記録と送信を続けて行う機能もあります。ただし、「コミット」という操作自体に送信が含まれるわけではありません。
プッシュしたのに見えないのは、なぜ？
「送る操作もしたはず」という場合は、送信の結果と、GitHubで見ている場所が関係します。代表的なのは、次のようなケースです。
送信の途中でエラーになっていた
プッシュのボタンを押しても、必ず送信が完了するとは限りません。
たとえば、接続に使う本人確認がうまくいかない、送り先を変更する権限がない、といった理由で止まることがあります。ほかの人が先に同じ場所を更新していたため、履歴を失わないように送信を拒否される場合もあります。GitHub公式の送信拒否の解説
この場合、PCでのコミットはできていても、GitHub側の更新は完了していないという状態です。同じ修正をコミットし直すより、送信時に出たメッセージが手がかりになります。
送った場所と、GitHubで開いている場所が違う
送信できていても、GitHubで別の場所を開いていると、変更は見えません。ここで初めて関係してくるのが、「リポジトリ」と「ブランチ」です。
リポジトリは、プロジェクトのファイルと変更の記録をまとめて管理する場所です。別の人のアカウントにある同名のプロジェクトを開いていれば、自分が送った場所とは違う可能性があります。
さらに、同じプロジェクトの中でも、「みんなが使う内容」と「自分が修正している途中の内容」を分けて作業することがあります。このように、変更の記録の流れを分ける仕組みをブランチと呼びます。
たとえば、紹介文を直すための作業用ブランチに、新しい文章を記録して送ったとします。GitHubで別のブランチを選んでいれば、その画面では古い文章が表示されることがあります。
送るところまでは成功していても、見ている側が違えば「変わっていない」と感じるわけです。
コミットに、見たい修正が入っていなかった
コミットがあることと、目的の修正がその中に入っていることも、別です。
たとえば、紹介文のファイルと別のファイルを編集し、別のファイルの変更だけを選んでコミットしたとします。そのコミットを送っても、紹介文はGitHubで変わりません。
Gitは、選んで記録した変更を送ります。PCで見えている最新の編集内容が、すべて自動的に送られるわけではありません。
作業用ブランチに送っても、mainは自動で変わらない
ここは、送信できているのに「反映されていない」と感じやすいところです。
GitHubでファイル一覧を開くと、mainという名前が表示されることがあります。これはブランチの名前のひとつで、プロジェクトの中心となる内容を管理するためによく使われます。自分が送った先は、このmainとは別の作業用ブランチかもしれません。作業用ブランチの変更が、プッシュだけでmainにも自動で入るわけではありません。
先ほどの紹介文なら、次の状態がありえます。
| GitHubで開いたブランチ | 表示される紹介文の例 |
|---|---|
| 修正を送った作業用ブランチ | 初心者向けの学習用アプリです |
| まだ修正を取り込んでいないmain | 学習用のアプリです |
作業用ブランチに新しい文章があるなら、その修正はGitHubへ届いています。 mainの文章が古いことだけで、送信失敗とは判断できません。
チームでは、変更を取り込んでよいか提案する「プルリクエスト」を作り、内容を確認してから取り込む「マージ」を行うことがあります。プルリクエストを作った段階は、まだ取り込み完了とは別です。GitHub公式のプルリクエスト解説
ここでのmainは取り込み先の一例です。実際にどこへ取り込むか、誰が確認するかは、チームによって異なります。
自分の場合はどれ？確認するなら、この3か所
理由が分かったうえで「自分の変更がどこまで届いているかも知りたい」と思ったら、普段使っているGitアプリやGitHubの画面で、次の3か所を見てみましょう。
| 見る場所 | 確かめたいこと | 分かること |
|---|---|---|
| Gitアプリの変更履歴 | 目的のファイルの修正が、そのコミットに含まれているか | 送りたい変更がPCに記録されているか |
| プッシュしたときの結果 | どこへ送り、成功したか。エラーが出ていないか | 送信で止まっていないか |
| GitHubのファイル一覧 | 送信先と同じ所有者・リポジトリ・ブランチを開いているか | 別の場所を見ていないか |
GitHubでは、ファイル一覧の上にあるブランチ選択欄で、表示するブランチを切り替えられます。修正を送ったブランチを選び、目的のファイルを開くと、内容を見比べられます。
さらに確かめたい場合は、PCとGitHubの変更履歴で、コミットの識別番号と変更内容を照合できます。番号は、同じ記録かを見分けるためのものです。GitHub公式のコミット解説
GitHubの対象ブランチに目的のコミットがあっても、現在の文章が違うなら、その後の変更で書き換えられていないか、同名の別ファイルを開いていないかも手がかりになります。
操作方法まで確認したい方は、Gitの基本的な流れで、変更を選んで記録し、共有する手順を確認できます。送信先が分からない場合やエラーが出た場合は、無理に進めず、分かったところまで伝えて相談して構いません。
説明用ファイルの紹介文を修正してコミットしました。プッシュしたかどうかは、まだ確認できていません。GitHubではmainを見ていますが、文章が古いままです。送信先のブランチと、送信結果をどこで確認できるか教えていただけますか。
送れないからといって、履歴を強制的に書き換える送信へ切り替えるのは避けましょう。ほかの人の変更に影響する場合があります。
補足：表示メッセージや「反映」の違い
ここからは、該当する表示や状況がある方だけ確認してください。
working tree cleanやEverything up-to-dateなら送信済み？
これらの表示だけでは、「見たい修正が、見たい場所に届いた」とは判断できません。
| 表示 | 意味と、分からないこと |
|---|---|
working tree clean | 通常の設定では、Gitの確認対象に未記録の変更がない状態。GitHubへの送信完了を表すものではない |
ahead ... | 設定された比較先の履歴より手元に先のコミットがある状態。PC内にある比較情報であり、その場でGitHubの最新状態を取得した結果ではない |
Everything up-to-date | そのプッシュで対象にしたブランチなどに、送信による更新が不要だった状態。目的の修正が記録されているか、送り先が正しいかまでは保証しない |
たとえば、修正した作業用ブランチとは別のブランチを送ろうとして、その別ブランチに更新がなければ、Everything up-to-dateと表示されることがあります。
また、working tree cleanは編集アプリで未保存の内容や、Gitの確認対象から外したファイルまで保証する表示ではありません。aheadも比較先が未設定なら表示されないことがあり、表示がないだけで送信済みとは判断できません。Git公式の状態表示、共有先の履歴との比較、プッシュ結果の意味
GitHubで直接編集した場合は？
ブラウザーでGitHub上のファイルを編集してコミットした場合、その記録はGitHub側に作られます。PCでコミットした今回の話とは作業場所が違うので、同じ記録をPCから送る必要はありません。
ただし、別のブランチに記録したなら、見たいブランチへの取り込みは別に必要です。GitHub公式のブラウザーでの編集手順
GitHubの内容は変わったのに、公開サイトが変わらないのは？
GitHubに変更が届くことと、利用者が見るサイトが更新されることも別の段階です。
公開サイトへ変更を届ける作業を「デプロイ」と呼びます。プッシュやマージをきっかけに自動で行う設定もありますが、どのブランチを公開するか、いつ処理が動くかはプロジェクトごとに異なります。
GitHub側に新しい内容があるなら、次に見るのは送信の成否ではなく、公開の設定や処理結果です。GitHub公式の公開元の設定例
まとめ
コミットはPCへの記録、プッシュは共有先への送信です。 コミットできてもGitHubが変わらないのは、この2つが別の操作だからです。
プッシュしたのに見えない場合は、送信が止まった、別の場所を見ている、コミットに目的の修正が入っていない、といった可能性があります。作業用ブランチへ届いていても、mainへの取り込みは別です。
まずは「記録できたこと」と「送れたこと」、そして「どこを見ているか」を分けて考えてみてください。変更をやり直す前に、今の状態を理解する手がかりになります。
関連記事
- 初めてGitを使うときの基本的な流れ｜変更から共有までを解説：理由が分かったあと、実際の操作手順を確認したい方へ。
- GitとGitHubの違いとは？初心者向けにやさしく解説：GitとGitHubそれぞれの役割から整理したい方へ。