git push - ローカルの変更をリモートに送信するコマンド

git push コマンドは、ローカルリポジトリで行ったコミットをリモートリポジトリに反映するためのコマンドです。
新しいブランチやタグを共有したり、チーム開発で変更をリモートに公開するときに利用されます。

構文（Syntax）
1. 主なオプション一覧
git pushとは？コミットとの違いと仕組み
originと -u（upstream）を正しく理解する
実行例：5分でgit push（クイックスタート）
実行例：基本レシピ集（ブランチ）
実行例：タグをpushする
実行例：pushの取り消し（安全ガイド）
エラー対処のチェックリスト
フォーク運用でのpush（origin＝自分のfork／upstream＝本家）
よくある質問（FAQ）
参考・参照リンク
関連コマンド
関連記事

構文（Syntax）

git push [オプション] [リモート名] [ブランチ名]

主なオプション一覧

オプション	説明	使用例
（なし）	デフォルトのリモート（通常は origin）と追跡ブランチに push	`git push`
`<リモート> <ブランチ>`	指定リモート・ブランチに push	`git push origin main`
`-u` / `--set-upstream`	上流ブランチを設定して push	`git push -u origin develop`
`--all`	すべてのブランチを push	`git push --all origin`
`--tags`	すべてのタグを push	`git push --tags`
`--delete`	リモートブランチやタグを削除	`git push origin --delete feature-x`
`--force`	強制的に push（履歴を書き換え可能）	`git push --force origin main`
`--force-with-lease`	他人の変更を保護しつつ強制 push	`git push --force-with-lease origin main`

git pushとは？コミットとの違いと仕組み

ワークツリー／ステージ／ローカル／リモートの関係

Gitでは、作業ディレクトリ（ワークツリー）で変更し、git addでステージ（インデックス）へ、git commitでローカル履歴に確定します。ここまでの変更は自分のPC内にとどまり、他のメンバーやCI/CDは知りません。git pushは、このローカル履歴をリモート（GitHub/GitLab等）に送信する操作で、チーム共有やデプロイの起点になります。よくある混同は「コミットしたのにPRに出ない」。それはpushしていないためです。仕組みを図にすると「ワークツリー → ステージ → ローカル履歴 →（push）→ リモート」。この流れを意識すると、トラブル時に「どの層で止まっているか」を切り分けやすくなります。

commitとpushの違い（ローカル履歴と公開の分離）

commit＝手元の履歴確定、push＝公開という役割分担を明確に持ちましょう。コミットメッセージはローカルに蓄積され、分岐ややり直し（rebase/reset）も安全に試せます。一方、pushは共有履歴を更新するため、保護ブランチやレビューの仕組みと密接です。「未pushのうちは履歴編集OK、push後は原則編集しない（どうしても必要な場合はチーム合意の上で--force-with-lease）」という運用ルールが事故を防ぎます。

「pullしてからpush」が安全な理由

リモート側が進んでいると非fast-forwardで弾かれます。先にgit fetchまたはgit pull --rebaseで手元を最新化し、コンフリクトをローカルで解決してからpushするのが基本。特に複数人並行作業や自動マージ禁止の保護ブランチでは、「更新を取り込んでから送る」が最短経路です。

originと -u（upstream）を正しく理解する

git remote add origin とHTTPS/SSHの選び方

新規リポジトリでは最初にリモートを登録します。

git remote add origin https://github.com/user/repo.git   # HTTPS
# もしくは
git remote add origin git@github.com:user/repo.git        # SSH

HTTPSは個人アクセストークン（PAT）での認証、SSHは鍵管理でパスワードレス接続が可能。チームやCIの方針に合わせて選び、後でgit remote set-url origin …で切り替えられます。

git push -u origin <branch> の意味（追跡ブランチの設定）

-u（--set-upstream）は追跡ブランチを設定します。初回だけgit push -u origin mainのように実行すると、以降は**git pushだけ**で同じリモート・同じブランチに送れます。Pull側もgit pullだけでOKになり、日々の操作が短縮されます。

追跡ブランチの確認・後付け（git branch -vv／--set-upstream-to）

現在の追跡先はgit branch -vvで確認できます。設定し忘れた場合は、

git branch --set-upstream-to=origin/main main
# もしくは push 時に -u を付け直す
git push -u origin main

とすれば後付け可能です。

push.default の推奨設定と挙動の違い

git config --global push.default simpleを推奨します。simpleは現在のブランチ名と同名のリモートブランチへだけpushし、事故を防止します。currentやmatchingは柔軟ですが、慣れるまではsimpleが安全です。

実行例：5分でgit push（クイックスタート）

リポジトリ初期化（既存ならスキップ）

mkdir demo && cd demo
git init

既存プロジェクトならこのステップは不要です。

リモート登録（HTTPS/SSH）

git remote add origin https://github.com/user/repo.git
# または
git remote add origin git@github.com:user/repo.git

初コミット（READMEなど）

echo "# demo" > README.md
git add README.md
git commit -m "chore: initial commit"

追跡付きで初回push：git push -u origin <branch>

git branch -M main
git push -u origin main

次回以降は git push だけ

以降、同じブランチでの更新は

git add .
git commit -m "feat: update"
git push

の3行で完了します。

実行例：基本レシピ集（ブランチ）

既存ブランチへpush

git switch main
git push origin main

追跡済みならgit pushのみでOK。

新規ブランチ作成→push

git switch -c feature/login
git push -u origin feature/login

-uで次回以降はgit pushのみ。

追跡ブランチを後付け

git branch -u origin/feature/login feature/login

リファスペックで別名へpush

git push origin feature/login:login-ui

ローカル名とリモート名を分けたい時に使います。

リモートブランチ削除（2通り）

git push origin :feature/old
# 同等
git push --delete origin feature/old

削除は影響が大きいので保護設定に注意。

実行例：タグをpushする

単発push

git tag v1.2.0            # 軽量
git tag -a v1.2.0 -m "Release 1.2.0"  # 注釈付き（推奨）
git push origin v1.2.0

注釈付きは作成者やメッセージが残り、リリース履歴として扱いやすくなります。

一括push

git push --tags

ローカルにある全タグを一度に送ります（不要な旧タグまで送らないよう注意）。

リリース連動

git push --follow-tags

注釈付きタグで付いたコミットに限り、当該タグを一緒に送ります。リリース運用と相性が良いオプションです。

タグ削除

git push origin :refs/tags/v1.1.0

タグ名を間違えやすいのでコピペ推奨。

実行例：pushの取り消し（安全ガイド）

公開履歴を壊さない

git revert <commit>
git push

チーム共有後の取り消しはrevert優先。履歴を壊さず、監査性も保てます。

直後の誤pushを戻す

git reset --hard HEAD~1
git push --force-with-lease

公開直後の誤pushなど、やむを得ない場合に限り使用。--force-with-leaseは他人の更新上書きを防ぎます。

復旧の最後の砦：git reflog の使いどころ

git reflog
git reset --hard <見つけたハッシュ>

「消したと思ったコミット」を救出できます。

--force を避ける判断基準

履歴を書き換える操作は保護ブランチで禁止し、必要時は合意＋工数見積。PRに記録を残し、影響範囲を明示しましょう。

エラー対処のチェックリスト

failed to push some refs（非fast-forward）への対処

git pull --rebase origin <branch>
# 解決後
git push

ローカルを最新化して再push。

認証・権限エラー（PAT/SSH/2FA/Collaborator）

HTTPSならPATの期限・スコープ、2FA有効時の設定を確認
SSHなら鍵の登録・権限・パーミッションを確認
リポジトリの書き込み権限（Collaborator/Team）を確認

保護ブランチ設定で拒否された場合

直接push不可。PR経由でレビュー・ステータスチェックを満たしてからマージ
どうしてもpushが必要なら、保護ルールの一時的緩和を管理者と合意

リモートURLの間違い・権限不足・ネットワーク起因

git remote -vでURLを確認、fork先に送っていないかを確認
VPN/プロキシ・企業FW・Large Mediaの制限を確認

大容量push・履歴肥大の注意（Git LFSの活用）

大きなバイナリはGit LFSへ移管
履歴に混入した場合はgit filter-repoなどでの履歴整理を検討

フォーク運用でのpush（origin＝自分のfork／upstream＝本家）

forkにpushし、本家をupstreamとして追加

git remote add upstream https://github.com/original/repo.git

origin＝自分のfork、upstream＝本家という役割を明確に。

本家との同期（fetch upstream→merge/rebase）

git fetch upstream
git switch main
git merge upstream/main   # もしくは git rebase upstream/main

乖離が大きくなる前に定期同期。

本家への反映はPull Requestで行う

forkにpushした変更をPRで提出。保護ブランチやCIのルールに沿ってレビューを通します。

よくある質問（FAQ）

Gitのpushとは？コミットとの違いは？

コミットは手元の履歴確定、pushはリモートへ公開。コミットだけでは他者は見られません。

特定ブランチにpushするには？

git push origin <branch>。追跡設定済みならgit pushだけでOKです。

git push -uは何をしている？

追跡ブランチの設定です。以降のgit push/git pullを短縮できます。

originとは何？

デフォルトのリモート名です。git remote add origin <URL>で登録します。

pushの取り消しはできる？安全な手順は？

公開後はgit revertが基本。やむを得ず履歴を戻すときは--force-with-lease＋チーム合意。

タグのpushはどうやる？

単発ならgit push origin <tag>、まとめては--tags、リリース連動は--follow-tagsが便利です。