2026年10月8日に、Git公式のgit-pushマニュアルとGitHubのremote repository資料を再読しました。pushはremoteのrefを更新し、送信先にない必要なオブジェクトを転送する操作で、作業ツリー全体を同期する機能ではありません。送信先、refspec、upstream、fast-forward条件を確認し、originは名前の慣例でURLや権限を示しません。pushが成功しても、他の人が取得できること、バックアップになること、本番公開が完了することは別に確かめます。
Gitのpushは、ローカルで記録した履歴を使って、別のリポジトリのブランチなどを更新する操作です。編集中のファイルを丸ごと同期する機能ではありません。送信先はGitHubのようなサービスだけでなく、同じPC内の別リポジトリにもできます。
30秒で要点
- 編集→add→commitで履歴を作り、pushで送信先の参照と必要なデータを更新します。未commitの変更は送られません。
git push origin mainは送信先とbranchを指定します。裸のgit pushは設定やupstreamに依存し、常に同じ行先になるとは限りません。- 拒否されたら送信先・権限・履歴を確認します。pushの成功と、他の人の取得、バックアップ、本番公開の成功は別に確かめます。
作業ファイル・履歴・送信先を分ける
まずGitの基礎、commitの基礎、リポジトリの基礎を区別すると、送る範囲が見えます。commitはローカルの記録、remoteは送信先につけた名前です。originはよく使われる名前ですが、名前だけでURLや権限は分かりません。
図のA・B・Cは架空のcommitです。remoteがBを指し、localにCが加わっていれば、pushでremoteのbranchをCへ進められます。一方、Cを作った後の編集Dはまだ作業ツリーにあり、pushに含まれません。図はファイル数や送信バイト数を表していません。
Git公式のpush説明では、参照の更新と送信先にない必要データの転送を扱います。「インターネット上へ全部保存する」と覚えるより、どのbranchをどこへ更新するかを確認してください。送信前に3つの場所を確認する
表が収まらない場合は、横にスクロールできます
| 場所 | 確認する内容 | 取り違えたときの例 |
|---|---|---|
| 作業ツリーとindex | 何を編集し、どの差分をcommitに含めるか | 関係ないファイルまでaddする |
| ローカルbranch | 送るcommitがどこまで記録されているか | 保存しただけの変更を送ったつもりになる |
| remoteとbranch | URL・push先・共有ルール | 違うrepositoryやbranchへ送る |
次は既存リポジトリで読み取りだけを行う確認例です。表示に秘密のURLや資格情報が含まれる環境では、出力を公開しないでください。
git status --short
git diff
git diff --cached
git remote -v
git branch -vvgit remote -vでfetch用とpush用を見て、必要ならgit remote get-url --push originで送信URLを調べます。remoteの公式説明のとおり、両URLは別設定になり得ます。git remote add origin URLは送信先を登録する構文で、URLという文字をそのまま送信先にする手順ではありません。
旧来の例git remote add origin https://github.com/username/repository.gitも置換前の見本です。既にoriginがあるときは繰り返し追加せず、管理者と送信先を確認します。この教材では外部URLへのpushは実行しません。
add・commit・pushを順番に行う
index.htmlの新しい節を記録するなら、対象を絞ったgit add index.htmlの後、差分を見てgit commit -m "新セクションを追加"を行います。git add .は現在の場所以下を広く対象にするため、対象にしたくない変更がないか確認が必要です。add自体は送信でもcommitでもありません。
送信先がorigin、送るローカルbranchがmainと確認できた場合の形は次のとおりです。実際の作業branch名に合わせて判断し、共有mainへの直接送信を許さない運用ではレビュー手順に従います。
git add index.html
git diff --cached
git commit -m "新セクションを追加"
git push origin mainmainはbranch名で、すべてのrepositoryでこの名前とは限りません。引数を省略したgit pushはpush先やpush.defaultなどの設定を使い、upstreamがなければ拒否される場合もあります。origin mainを省略しても同じ、と決めつけないでください。
旧来の制作例を、送信と公開に分けて読む
表が収まらない場合は、横にスクロールできます
| 制作場面 | 記録する例 | push後に別途確認すること |
|---|---|---|
| 新記事 | new-article.mdを編集し、git add new-article.md、git commit -m "新記事を追加" | 公開用buildと記事URL |
| デザイン更新 | style.cssを編集し、git add style.css、git commit -m "デザインを更新" | 対象画面の表示とキャッシュ |
| 問い合わせフォーム | git add contact-form.html、git commit -m "お問い合わせフォームを追加" | 入力検証・送信先・本番の動作 |
| 商品検索 | search.jsとsearch.cssを編集し、git add search.js search.css、git commit -m "商品検索機能を追加" | 検索結果・権限・性能 |
いずれも送信の形は、確認済みのgit push origin mainなどです。表は機能の実装や公開が済んだことを示しません。CI/CDが設定されていても、テスト失敗や承認待ちで公開が止まることがあります。deployの基礎とWeb制作の全体像で、その後の責任を分けて考えます。
pushが拒否されたときの順序
表が収まらない場合は、横にスクロールできます
| 観測 | 最初に確かめること | 避けたい対応 |
|---|---|---|
| remoteが見つからない | git remote -vの名前とURL | 似たURLを推測して登録する |
| 認証・権限の拒否 | 自分のアカウントと対象branchの規則 | 他人の資格情報を借りる |
| non-fast-forward | remoteに自分が含めていない履歴があるか | 直ちにforceする |
| upstreamがない | 今いるbranchと送信先の対応 | 裸pushがmainへ送ると思い込む |
履歴の違いはまず取得して観察します。以下は取得と比較の例で、作業ツリーへ統合する命令は含みません。
git fetch origin
git log --oneline --graph --allgit pullは単なるダウンロードではなく、fetchの後に現在branchへ統合します。pullの公式説明と初心者向けpull解説を確認し、チームのmerge/rebase方針に合わせます。競合は、統合方法を決めた後に解消する問題です。
forceは単に警告を消す機能ではなく、通常拒否される参照更新を許すものです。他の人の履歴を失うおそれがあります。force-with-leaseも、期待する参照の検査を加えるだけで、あらゆる誤操作を防ぐ保証にはなりません。
共有・復元・公開をそれぞれ確かめる
同僚はpushされただけでは自分のファイルが変わりません。fetchやgit pullなど、自分の作業状況に合う取得・統合が必要です。新しく作業を始めるときのgit cloneと、既存の作業場所を更新するpullも役割が違います。
送信済みの履歴は復元経路の一つになりますが、未commit・未pushの変更、無視したファイル、秘密情報、外部DB、開発環境全体はそれだけでは戻りません。「GitHubがあるから完全なバックアップ」とは言えません。合意した保存対象と復元手順を別途確認してください。
学習では、一時フォルダーのbare repositoryを送信先にして、未commitのファイルが転送されないことや、二人の履歴が分かれると拒否されることを試せます。外部認証・ホスティングの保護設定・CI/CD・本番公開は、そのローカル実験の検証範囲に入りません。最初の目的はプログラミングの基礎と同様に、操作と結果を一つずつ対応させることです。