git pushの使い方とオプション一覧！-uの意味やエラー・force対策まで完全解説

git push コマンドは、ローカルリポジトリで作成したコミットをリモートリポジトリ（GitHubやGitLabなど）へ送信・反映させるための重要コマンドです。
本記事では、git push の基本的な使い方から、初回プッシュ時に必須となる -u（--set-upstream）オプションの仕組み、安全な開発に不可欠な --force の危険性と --force-with-lease の使い分け、さらによくあるエラー（rejectedやupstream未設定など）のトラブルシューティングまでを分かりやすく解説します。

構文（Syntax）と主要オプション一覧

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

主なオプション一覧

オプション	説明	使用例
（なし）	追跡ブランチ（upstream）が設定済みのリモート・ブランチへ push	git push
<リモート> <ブランチ>	指定したリモートとブランチへ push	git push origin main
-u / --set-upstream	上流ブランチ（追跡関係）を設定して push（初回推奨）	git push -u origin feature-a
--force / -f	リモートの履歴を強制上書き（※危険）	git push --force origin feature-a
--force-with-lease	リモートが変更されていない場合のみ安全に強制 push	git push --force-with-lease origin feature-a
--all	すべてのローカルブランチを一度に push	git push --all origin
--tags	ローカルの全タグを push	git push --tags
--follow-tags	コミットと関連する注釈付きタグのみを一緒に push	git push --follow-tags
--delete	リモートブランチまたはタグを削除	git push origin --delete feature-old
--dry-run	実際には送信せず、何が push されるか事前確認	git push --dry-run origin main

git pushとは？コミットとの決定的な違いと仕組み

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

Gitでファイルを変更してからリモートリポジトリに反映されるまでには、4つのエリアが存在します。

• ワークツリー（作業ディレクトリ）: 実際にファイルを編集・作成する場所
• ステージ（インデックス）: git add でコミット対象として登録する一時領域
• ローカルリポジトリ: git commit で自分のPC内に変更履歴を記録・確定する場所
• リモートリポジトリ: git push でチーム共有やバックアップのためにサーバー（GitHub等）へ送信する場所

全体的なデータの流れは以下のようになります。

[ ワークツリー ] ──( git add )──> [ ステージ ] ──( git commit )──> [ ローカル履歴 ] ──( git push )──> [ リモート ]

commitとpushの違い（「コミットしたのに共有されない」の原因）

初心者がよく戸惑うのが「git commit をしたのにGitHubやGitLabのプルリクエストに変更が反映されない」という問題です。

git commit はあくまで手元のPC内（ローカル）に履歴を保存する操作です。他のメンバーやWeb上のリモートリポジトリへ変更を公開するには、必ず git push を実行してデータをアップロードする必要があります。

なぜ「pushする前にpull/fetch」が必要なのか？

チーム開発では、自分が作業している間に他のメンバーがリモートリポジトリを更新していることがあります。リモートの履歴が自分のローカルより進んでいる状態のまま git push しようとすると、Gitは履歴の整合性を保つために push を拒否（rejected）します。

そのため、安全に push するには、あらかじめ git fetch または git pull --rebase で最新のリモート変更を取り込んでから push するのが基本のルールです。

初回プッシュと -u（–set-upstream）オプションの役割

初回プッシュの基本手順（クイックスタート）

ローカルで新規プロジェクトを作成し、GitHubなどのリモートリポジトリへ初めて push するまでの手順は次の通りです。

# 1. ローカルリポジトリの初期化とファイル生成
git init
echo "# My Project" > README.md

# 2. ステージングと初回コミット
git add README.md
git commit -m "feat: initial commit"

# 3. デフォルトブランチ名を main に設定
git branch -M main

# 4. リモートリポジトリの登録（HTTPSまたはSSH）
git remote add origin https://github.com/username/repository.git

# 5. 上流ブランチを設定して初回push
git push -u origin main

git push -u origin <branch> の意味とメリット

-u オプション（--set-upstream の略）は、ローカルブランチに対してリモートの「上流ブランチ（追跡ブランチ）」を関連付ける設定を行います。

初回に git push -u origin main を実行しておくと、Gitは「ローカルの main ブランチは origin/main を追跡する」と記憶します。これにより、次回以降は引数を省略して単に：

git push
git pull

と入力するだけで、正しく該当するリモートブランチとの送信・受信が行えるようになります。

-u を付け忘れた場合の後付け方法

もし初回 push 時に -u を付け忘れて単に git push origin main と実行した場合でも、後から簡単に追跡設定を追加できます。

# 方法1: 再度 -u を付けて push する
git push -u origin main

# 方法2: git branch コマンドで上流ブランチを直接設定する
git branch --set-upstream-to=origin/main main

追跡ブランチの確認（git branch -vv）

各ローカルブランチがどのリモートブランチを追跡しているかは、git branch -vv コマンドで確認できます。

$ git branch -vv
* main     a1b2c3d [origin/main] feat: add new header
  feature  e5f6g7h [origin/feature: ahead 1] update docs

ブランチ名の横に [origin/main] のように表示されていれば、上流ブランチが正常に設定されています。

強制プッシュ（–force）の危険性と安全な代替案（–force-with-lease）

git push --force (-f) がなぜ危険なのか？

git push --force（または -f）は、リモートリポジトリの履歴をローカルの状態で強制的に書き換える・上書きするコマンドです。

ローカルで git rebase や git reset を行って履歴を整えた後に使われることがありますが、チーム開発で軽易に使用すると重大な問題を引き起こします。

• 他人のコミットを消去してしまう: 他のメンバーがリモートに push していたコミットが存在しても、それを完全に上書き抹消してしまいます。
• チーム全体の環境壊滅: 他のメンバーのローカル履歴とリモート履歴に整合性がなくなり、コンフリクトや混乱が発生します。

より安全な代替案：git push --force-with-lease

強制 push が必要な場合、--force の代わりに必ず --force-with-lease オプションを使用するのが世界共通のベストプラクティスです。

git push --force-with-lease origin feature-branch

--force-with-lease の仕組み:
自分が最後にリモートを fetch してから、他の人がさらに新しいコミットを push していないかをチェックします。もし他の人が更新していた場合は push を自動拒否 してくれるため、他人の作業結果を意図せず消してしまう事故を防止できます。

公開済みコミットを消さずに取り消す方法（git revert）

すでにリモートへ push してしまったコミットを取り消したい場合は、強制 push で履歴を書き換えるのではなく、打ち消しコミットを作成する git revert を使うのが安全です。

# 指定したコミットの変更を打ち消すコミットを作成
git revert <コミットハッシュ>

# 通常通り push（強制 push は不要）
git push

git revert であれば過去の履歴を壊さず安全に変更を元に戻せるため、共同開発や本番環境でのデプロイブランチ（main / master）で推奨されます。

【トラブルシューティング】git pushでよく発生するエラーと解決策

エラー①: ! [rejected] ... (non-fast-forward) / fetch first

エラーメッセージ例：

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'https://github.com/username/repository.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing

【原因】
リモートリポジトリに、あなたのローカルPCには存在しない最新コミット（他のメンバーの変更やWeb画面でのREADME追加など）があるためです。

【解決策】
リモートの最新状態を取り込んでから再 push します。

# リモートの変更を取り込む（rebaseが推奨）
git pull --rebase origin main

# コンフリクトがなければそのまま push
git push origin main

エラー②: fatal: The current branch has no upstream branch

エラーメッセージ例：

fatal: The current branch feature-login has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature-login

【原因】
新規作成したローカルブランチに、上流ブランチ（-u）がまだ登録されていない状態で単に git push と入力したためです。

【解決策】
エラーメッセージの提示通り、-u（または --set-upstream）オプションを指定して push します。

git push -u origin feature-login

エラー③: error: src refspec main does not match any

エラーメッセージ例：

error: src refspec main does not match any
error: failed to push some refs to 'https://github.com/username/repository.git'

【原因】
以下のいずれかが原因です。

• ローカルでまだ1つも git commit を実行していない
• 指定したブランチ名（main）が存在せず、ローカルのブランチ名が master になっている

【解決策】
git status や git branch で現在のブランチ名とコミットの有無を確認します。

# コミットが存在することを確認
git log

# ブランチ名を main に変更して push
git branch -M main
git push -u origin main

エラー④: Permission denied (publickey) / 認証エラー

エラーメッセージ例：

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

【原因】
SSH接続用の鍵（公開鍵）がGitHub/GitLabに登録されていないか、認証トークン（PAT: Personal Access Token）が無効になっているかです。

【解決策】
SSHキーの設定または接続確認を行います。

# SSHの接続テスト
ssh -T git@github.com

# 成功メッセージ"Hi username! You've successfully authenticated..."が出ればOK

未登録の場合は ssh-keygen で公開鍵を生成し、GitHubの 設定（Settings > SSH and GPG keys）に登録してください。

エラー⑤: remote: Protected branch hook declined （保護ブランチエラー）

エラーメッセージ例：

remote: Personal account rules or branch protection rules prohibit pushing to main.
! [remote rejected] main -> main (protected branch hook declined)

【原因】
GitHub等のリポジトリ設定で main / master ブランチへの直接 push が禁止（保護ルール適用）されているためです。

【解決策】
直接 push せず、機能ブランチを作成して push し、プルリクエスト（PR）を作成してコードレビュー・マージを行います。

# 作業ブランチを作成して切替
git switch -c feature/my-update

# トピックブランチを push
git push -u origin feature/my-update
# その後、GitHub上でプルリクエストを作成

エラー⑥: fatal: 'origin' does not appear to be a git repository

【原因】
リモート名 origin が登録されていないか、リポジトリURLが間違っています。

【解決策】
登録情報を確認し、正しいURLを設定します。

# リモート一覧とURLの確認
git remote -v

# 正しいURLでリモートを追加（未登録の場合）
git remote add origin https://github.com/username/repository.git

# すでに誤ったURLが登録されている場合の変更方法
git remote set-url origin https://github.com/username/repository.git

目的別！git pushの実務レシピ集

レシピ1: 新規ブランチを作成してリモートへpushする

# ブランチ作成と切り替え
git switch -c feature/user-auth

# 変更を加えた後コミット
git add .
git commit -m "feat: add user auth logic"

# 上流設定付きでpush
git push -u origin feature/user-auth

レシピ2: リモートブランチを削除する

マージ済みの不要になったリモートブランチを削除する手順です。

# リモートブランチの削除（推奨記法）
git push origin --delete feature/user-auth

# 昔からあるコロンを用いた同等記法
git push origin :feature/user-auth

レシピ3: タグを作成してリモートにpushする

リリースバージョンなどを管理する「タグ」は、通常の git push では送信されません。

# 1. 注釈付きタグを作成（推奨）
git tag -a v1.0.0 -m "Release version 1.0.0"

# 2. 特定のタグのみ push
git push origin v1.0.0

# ローカルにある全タグを一括 push
git push --tags

# コミットと関連する注釈付きタグのみ一緒に push
git push --follow-tags

レシピ4: ローカルと異なる名前のリモートブランチへpushする

リファスペック（ローカル名:リモート名）を使ってブランチ名を指定します。

# ローカルの dev ブランチをリモートの feature-dev へ push
git push origin dev:feature-dev

レシピ5: Fork（フォーク）リポジトリから本家（upstream）へ連携する

OSS開発やフォーク運用では、自分のフォークリポジトリを origin、本家リポジトリを upstream として登録します。

# 本家リポジトリを upstream として追加
git remote add upstream https://github.com/original-owner/repo.git

# 自分のフォーク（origin）へ push
git push -u origin feature-fix

# 本家の最新変更を取り込む場合
git fetch upstream
git merge upstream/main

よくある質問（FAQ）

Q1. git push -u は毎回実行する必要がありますか？

いいえ、初回のみで大丈夫です。
新しいブランチを作成して最初に push する時だけ -u を付けておけば、次回以降はそのブランチ上で単に git push と打つだけで自動的に同じリモートブランチへ送信されます。

Q2. コミット（git commit）せずに git push するとどうなりますか？

「Everything up-to-date」（すべて最新です）と表示され、何も送信されません。
git push はローカルリポジトリに保存されたコミットを送信するコマンドです。ワークツリーやステージ上の未コミットな変更は送信されないため、必ず事前に git add と git commit を行なってください。

Q3. 誤って –force でリモート履歴を上書きしてしまった場合の復旧方法は？

他のチームメンバーのローカル環境に消えてしまったコミットが残っていれば、そのメンバーから再 push してもらうか、git reflog コマンドで消去前のコミットハッシュを探して復元が可能です。

# 過去のHEADの移動履歴を確認
git reflog

# 上書き前の状態にローカルを戻して再push
git reset --hard HEAD@{1}
git push --force-with-lease origin branch-name

Q4. 大容量ファイル（動画・Zipなど）で push がエラーになる場合は？

GitHub等では1ファイル100MB以上のファイルは push できません。大容量ファイルを扱う場合は Git LFS（Large File Storage） を導入してください。

# Git LFS のインストールと設定
git lfs install
git lfs track "*.zip"
git add .gitattributes

参考・参照リンク

• Git公式ドキュメント（git push）
• Pro Git 日本語版（無料オンライン書籍）
• GitHub Docs: Pushing commits
• Atlassian Git Tutorials: Git push
• Backlog Git入門：リモート操作（push/pull/fetch）

関連コマンド

• git pull — リモートリポジトリの変更をローカルに取り込む
  /command/git/git-pull/
• git fetch — リモートの最新情報をローカルに取得（マージはしない）
  /command/git/git-fetch/
• git remote — リモートリポジトリの追加・削除・確認
  /command/git/git-remote/
• git branch — ブランチの作成・削除・一覧確認・追跡設定
  /command/git/git-branch/
• git config — Gitの設定（push.default など）の変更
  /command/git/git-config/