プッシュとは
この記事の結論
- プッシュとは、手元に記録したコミットを、共有先のリモートリポジトリへ送る操作です。送って初めて、その変更が自分以外からも見えるようになります。
- 手順はコミットまで終えてから git push。初回だけ git push -u origin ブランチ名 で送り先を覚えさせておくと、次からは git push だけで済みます。
- 断られたときは、たいてい自分がまだ持っていないコミットが共有先にあります。先に git pull で取り込んでから送り直します。強制的に上書きする操作は、共有済みの履歴には使いません。
ぷっしゅ／Push
手元に記録したコミットを、共有先のリモートリポジトリへ送る操作のことです。
最終更新: 2026-09-17
プッシュとは何か（意味と読み方）
プッシュとは、手元のリポジトリに記録したコミットを、共有先のリポジトリへ送る操作のことです。読み方は「ぷっしゅ」、英語では push と書き、「押し出す」という意味です。送り先はGitHubなどのサービス上に置かれることが多く、この共有先をリモートリポジトリと呼びます。
手元のリポジトリと共有先のリポジトリは、別々に履歴を持っています。コミットした時点では、その変更は手元にしかありません。プッシュして初めて、共有先にも同じ記録が並び、他の人が取りに行けるようになります。手元のパソコンが壊れたときに困らない、という意味でのバックアップにもなります。
共有先には名前が付いていて、既定では origin が使われます。git push origin main と書いたときの origin がその名前、main が送るブランチです。コマンドの正式な説明はgit-push（git-scm.com）にまとまっています。
コミットとプッシュの違い
初心者がいちばん取り違えるのがこの2つです。どちらも「保存」に見えますが、保存される場所と、見える範囲が違います。
| 観点 | コミット | プッシュ |
|---|---|---|
| 何をするか | 変更を1つの区切りとして履歴に記録する | 記録したコミットを共有先へ送る |
| どこに残るか | 自分のパソコンの中 | 共有先のリポジトリ |
| 誰が見えるか | 自分だけ | そのリポジトリを見られる人全員 |
| やり直しやすさ | 手元だけなので直しやすい | 送ったあとは他の人に影響するため直しにくい |
つまり、コミットは何度やっても他の人に影響しないということです。区切りごとにこまめに記録しておき、まとまったところで送る。この順番にしておくと、送る前に内容を読み返す機会が自然に生まれます。
プッシュの基本的な手順
送るまでの流れは4段階です。いきなり git push を打つのではなく、何を送ろうとしているかを先に確認します。
| 順番 | やること | コマンドの例 |
|---|---|---|
| 1 | 変更されたファイルを確認する | git status |
| 2 | 記録に含める変更を選ぶ | git add ファイル名 |
| 3 | 説明を添えて記録する | git commit -m "説明文" |
| 4 | 共有先へ送る | git push |
新しく作った枝を初めて送るときだけは、送り先を教える必要があります。git push -u origin ブランチ名 と打つと、その枝の送り先が記録され、次回からは git push だけで済みます。GitHubを使っている場合の流れはコミットをリモートリポジトリにプッシュする（GitHub Docs）にも手順があります。
プッシュが断られたときに見るところ
プッシュは、条件が整っていないと拒否されます。よくあるのは次の4つです。
- 共有先のほうが進んでいる：自分がまだ持っていないコミットが共有先にあると、上書きを避けるために止められます。
git pullで取り込み、必要なら合流させてから送り直します。 - 認証で止まっている：送る権限があるかどうかの確認です。サービスによって、アクセストークンやSSH鍵での認証が必要になります。
- ブランチが保護されている：
mainへの直接のプッシュを禁止している設定がよくあります。この場合はプルリクエスト経由で取り込みます。 - ファイルが大きすぎる：1ファイルの大きさに上限が設けられていることがあります。上限値は利用しているサービスの案内を確認してください。
どれも「送れなかった」という結果は同じですが、直し方はまったく違います。画面に出ているメッセージを読み飛ばさず、rejected（拒否）なのか認証の失敗なのかを先に切り分けると、無駄な試行を減らせます。エラー文の読み方に慣れていないうちは、エラーをAIに直させる手順：貼り方・情報の渡し方・切り分けの手順が役に立ちます。
プル（pull）・フェッチ（fetch）との関係
プッシュが「送る」操作なら、逆向きの操作が2つあります。並べると役割が分かれます。
| 操作 | 向き | 何が起きるか |
|---|---|---|
| プッシュ（push） | 手元 → 共有先 | 手元のコミットを共有先へ送る |
| フェッチ（fetch） | 共有先 → 手元 | 共有先の最新を取ってくるだけ。作業中のファイルは変わらない |
| プル（pull） | 共有先 → 手元 | 取ってきて、そのまま手元の枝に合流させる |
つまり、プルはフェッチとマージをまとめて行う操作です。取ってくるだけで中身を先に確認したいときはフェッチ、そのまま取り込んでよいときはプル、と使い分けます。複数人で同じ枝を触っているときは、作業を始める前にプルしておくと、送る段階で断られにくくなります。
プッシュを使うときの注意点
- 秘密の情報を送らない：パスワードやAPIキーを送ってしまうと、共有先の履歴に残ります。環境変数や除外設定を使い、そもそも記録対象に入れないのが確実です。送ってしまった場合は、履歴を直すだけでなく、その鍵自体を作り直してください。
- 強制的な上書きを安易に使わない：共有済みの履歴を書き換えて送ると、他の人が持っているコミットが辿れなくなることがあります。
- 動く状態で送る：共有先に壊れた状態が並ぶと、取りに行った人の手元でも壊れます。
- 送り先と枝を確認する：どのリモートの、どの枝に送ろうとしているかを
git statusで確かめてから実行します。
リモートとのやり取りをひととおり追いたい場合は、Pro Git 日本語版（git-scm.com）の「Gitの基本」「Gitサーバー」の章に、送受信の流れがまとまっています。
関連用語
関連記事
よくある質問
Q1. プッシュとは何ですか？
手元のリポジトリに記録したコミットを、共有先のリモートリポジトリへ送る操作のことです。送って初めて、その変更が他の人からも見えるようになります。GitHubなどを使っている場合、送り先の既定の名前は origin です。
Q2. コミットしただけでは共有されないのですか？
共有されません。コミットは自分のパソコンの中にある履歴への記録で、その時点では他の人には見えません。共有するには、コミットのあとにプッシュが必要です。逆に言えば、コミットは何度行っても他の人に影響しません。
Q3. プッシュが拒否されるのはなぜですか？
自分がまだ持っていないコミットが共有先にある場合に多く起きます。上書きを避けるために止められているので、git pull で取り込み、必要なら合流させてから送り直します。認証の失敗やブランチの保護設定が原因のこともあります。
Q4. プッシュとプルは何が違いますか？
プッシュは手元から共有先へ送る操作、プルは共有先から取ってきて手元の枝に合流させる操作です。取ってくるだけで合流はしないフェッチという操作もあり、プルはフェッチとマージをまとめて行うものと考えると整理できます。
Q5. 間違えてプッシュしたら取り消せますか？
打ち消す内容の新しいコミットを積んで送り直すのが安全な方法です。共有済みの履歴を書き換えて強制的に上書きすると、他の人の手元と食い違います。パスワードやAPIキーを送ってしまった場合は、履歴を直すだけでなく、その鍵自体を作り直してください。