プッシュとは — git pushの仕組みと必要なタイミング

Gitにおけるプッシュとは

Git pushは、ローカルリポジトリからリモートリポジトリにコミットを転送するコマンドです。変更を開発者のローカルマシンにのみ保存するcommitとは異なり、プッシュはそれらの変更をチーム全体に公開します。Pushは、Pull Requestの作成とデプロイ前の必須ステップです。

Gitのアーキテクチャでは、各開発者が自分のローカルリポジトリで作業することを前提としています。コミットはローカルで作成され、開発者がプッシュすることを決定するまで蓄積されます。これにより自由が得られます。多くのローカルコミットを作成し、実験し、同僚に影響を与えることなく履歴を書き換えることができます。

# originリモート、mainブランチにプッシュ
git push origin main

# 現在のブランチをupstream付きでリモートにプッシュ
git push -u origin feature/new-dashboard

# 一致する名前のすべてのブランチをプッシュ
git push --all origin

# リース付きフォースプッシュ（安全なフォースプッシュ）
git push --force-with-lease

プッシュ後、リモートリポジトリはrefs（ブランチ参照）を更新して新しいコミットを指すようにします。他の開発者はgit pullまたはgit fetchを介してこれらの変更を取得できます。このコミットの交換がコラボレーティブ開発の基盤を形成します。

git pushの仕組み

git pushコマンドはローカルブランチとリモートブランチを比較し、不足しているコミットのみを転送します。Gitはすべてのファイルを再送信するのではなく、デルタのみを転送するため、大きなリポジトリでもプッシュが高速です。Gitプロトコルはスマート転送を使用し、転送データ量を最小限に抑えます。

リモートブランチにローカルに存在しないコミットが含まれている場合、プッシュは拒否されます。これは変更の損失を防ぐ保護メカニズムです。この状況では、開発者は最初にgit pullを実行し、変更をマージしてから、再度プッシュする必要があります。代替案はフォースプッシュで、リモートブランチを上書きしますが、注意して使用する必要があります。

リモートリポジトリの理解が適切なプッシュの鍵です。通常、originがデフォルトのリモートリポジトリ名です。git remote -vコマンドはリモートリポジトリとそのURLのリストを表示します。複数のリモートを追加できます（例：メインリポジトリ用のoriginとフォーク用のupstream）。

変更をプッシュすべきタイミング

基本ルール：論理的に完了した作業段階ごとにプッシュします。開発者がタスクまたはその一部を完了したら、プッシュのタイミングです。ただし、ビルドを壊す未完了の作業をプッシュすることは推奨されません。ビルドが壊れていないことが、任意のブランチにプッシュするための最小要件です。

チーム開発では次のリズムが採用されています。朝 — 同僚の変更を取得するためにgit pull、日中 — 数回のコミットと1〜2回のプッシュ、夕方 — 完了したすべてのタスクの最終プッシュ。開発者がプッシュする頻度が高いほど、マージ競合のリスクが低くなり、作業の進捗がより透明になります。

• タスク完了後 — コミットして最終ソリューションをフィーチャーブランチにプッシュ
• 退社前 — 未完了の作業をフィーチャーブランチにプッシュ（mainにはしないでください！）
• PR作成前 — すべてのコミットがプッシュされ、レビュー可能であることを確認
• リベース後 --force-with-leaseで自分のフィーチャーブランチにプッシュ

安全なプッシュのルール

安全なプッシュとは、データの損失やチーム内の競合を防ぐ一連のルールです。第一かつ最も重要なルール：プロジェクトで直接デプロイが設定されていない限り、mainまたはmasterブランチに直接プッシュしないでください。現代のチームでは、mainブランチの保護はGitHubブランチプロテクションレベルで設定されます。

第二のルール：プッシュ前にリモートブランチと同期します。マージ時のマージコミットを避けるためにgit pull --rebaseを実行します。これにより履歴がシンプルで線形になります。プッシュが拒否された場合 — 単純なフォースプッシュは使用せず、まずリモートブランチにどのコミットが現れたかを確認します。

第三のルール：送信前に自動的にテストとリンターを実行するpre-pushフックを設定します。テストが失敗した場合 — プッシュはブロックされます。このようなフックはHuskyまたはGitフック（.git/hooks内のpre-pushファイル）を介して設定されます。

第四のルール：大きなバイナリファイルをプッシュしないでください。Gitはバイナリアーティファクトの保存用に設計されていません — リポジトリを肥大化させ、操作を遅くします。大きなファイルにはGit LFS（Large File Storage）を使用します。バイナリがすでにプッシュされて履歴にある場合は、git filter-branchで削除する必要があります。

プッシュが失敗した場合の対処法

プッシュ失敗の最も一般的な原因は、リモートブランチにローカルに存在しないコミットが含まれていることです。これは別の開発者が同じブランチに変更をプッシュした場合に発生します。解決策：git pullを実行し、競合を解決してから再度プッシュします。

# プッシュが拒否されました — 最初にfetchとrebaseを実行
git fetch origin
git rebase origin/main
# 競合を解決し、その後:
git push --force-with-lease

# または単にリモートの変更をマージ
git pull origin main
git push

第二の原因 — ブランチへの書き込み権限の不足。mainブランチがブランチプロテクションルールで保護されている場合、直接プッシュは禁止されています。解決策：フィーチャーブランチにプッシュし、Pull Requestを作成します。保護設定は通常、GitHub設定またはGitLabの保護ブランチを介して管理されます。

第三の原因 — 認証の問題。期限切れの資格情報、SSHへの切り替え、または個人アクセストークンの変更。解決策：リモートURL（git remote -v）を確認し、資格情報を更新します。2021年以降、GitHubはHTTPSのパスワード認証を廃止しました — 個人トークンまたはSSHキーを使用します。