リモートと同期（remote / push / pull）
手元のリポジトリと、GitHubなどサーバー上のリポジトリ（リモート）をやり取りすると、他の人と変更を共有できます。リモートの登録状況は git remote で確認し、手元のコミットを送り出すのが git push、サーバー側の変更を取り込むのが git pull です。一般に既定のリモートは origin という名前で登録されます。チーム開発では push の前に pull で最新を取り込む流れが基本になります。
ここまでは自分のPCの中だけ（ローカル）の操作だった。だが、もしこのPCが壊れたら、積み上げた履歴は失われてしまう。
そこで登場するのがリモート（git-remote）リポジトリだ。これを使うと別のサーバー上に履歴を置けるようになる。代表的なのが GitHub などのサービスだ。
リモートにコミットを置くことで、PCが壊れても履歴を失わないバックアップになる。さらに、他の人と同じリポジトリを共有して共同作業もできる。
最初に押さえておきたいのは、リモートは必須ではないということだ。「戻せる・履歴が残る・枝を分けて試せる」という Git の利点は、すべてローカルだけで手に入る。
リモートは「他の場所にも置きたい」「他人と共有したい」となったときに足せばよい、追加の仕組みだと考えてほしい。まずローカルでコミットに慣れ、必要になったらリモートを使い始める、という順番が分かりやすい。
📮 送り先を登録する git remote
手元のリポジトリに対して、変更を送ったり受け取ったりする相手のサーバーを登録するのが git remote add だ。
書式は git remote add <名前> <URL> だ。たとえば git remote add origin https://github.com/taro/myproject.git のように使う。
ここで付ける名前は、送り先につける「名札」だ。慣習上は最初の1つに origin という名前を付ける。origin はただの慣習名であって特別な意味はなく、複数のサーバーを使いたいときは別の名前も付けられる。
いまどんなリモートが登録されているかは git remote -v で一覧できる。取得（fetch）用と送信（push）用の URL が表示される。
なお、git clone（git-clone）でリポジトリを複製した場合は、複製元が origin として自動的に登録済みなので、この登録作業は不要だ。
↕ 送り出す git push と取り込む git pull
登録したサーバーとのやり取りは、向きの違う2つの操作で覚える。手元のコミットをサーバーへ送り出すのが git push、サーバー側の変更を手元へ取り込むのが git pull だ。
初めて push するときは、git push -u origin main のように書く。-u（--set-upstream の短縮形）は「このローカルの main の送り先は origin の main だ」と紐付ける指定だ。最初の一回だけ付ければ、以後は git push と打つだけで同じ送り先へ送れるようになる。
成功すると「[new branch] main -> main」のように、新しい枝がサーバー側に作られたことが表示される。
一方 git pull は、他の人がサーバー側に加えた更新があれば手元に取り込み、何も無ければ「Already up to date.（最新です）」と表示される。pull は内部的には、サーバーの最新を取ってくる fetch と、それを手元に合流させる merge の2つをまとめて実行している。
👀 先に覗くだけの git fetch
取り込む前に「サーバー側に何が来ているか」だけ先に覗くこともできる。取ってくる操作には、もう一段おだやかな git fetch がある。
git pull が「取ってきて手元に合流まで」やるのに対し、git fetch は「取ってくるだけで、手元にはまだ合流しない」操作だ。
fetch した後は origin/main のような名前で「サーバー側の最新がどこまで来ているか」を確認でき、内容を見てから自分のタイミングで git merge して合流させられる。サーバー側に何が来ているかを先に確かめてから取り込みたいときに、この使い分けが効いてくる。
慣れないうちは pull だけでも実務は回る。ただ、fetch という安全側の選択肢があることは知っておくと役立つ。
🤝 共同作業のリズムと、push が拒まれる理由
チームで1つのリモートを共有して開発するときの基本リズムは「push の前にまず pull」だ。
自分が作業している間に、他の人が先にサーバーへ変更を送っているかもしれない。その状態でいきなり push しようとすると、サーバー側のほうが進んでいるために push が拒否される。
これは Git が「あなたはまだ取り込んでいない他人の変更があるので、上書きさせません」と守ってくれているのだ。
このときは、まず git pull で相手の変更を取り込み、必要ならコンフリクトを解決してから、あらためて git push する。この「pull してから push」を習慣にすると、共同作業での衝突をかなり防げる。
なお、pull しようとしたときに手元で中途半端な編集が残っていると、合流の邪魔になって警告が出ることがある。そんなときは git stash で編集を一時的に棚へ退避し、pull を済ませてから git stash pop で戻す、という手順が役立つ。
🔑 認証と、Git と GitHub の違い
最初に push するとき、本人確認のための認証を求められる。HTTPS の URL を使う場合、いまはパスワードの代わりにアクセストークンと呼ばれる文字列を使うのが主流だ。具体的な発行手順や認証方法はサービスや環境ごとに異なるため、画面の案内に従ってほしい。
ここで混同しやすいのが Git と GitHub の関係だが、両者は別物だ。
Git は手元で動くバージョン管理の道具そのものだ。GitHub や GitLab は、その Git リポジトリを置いておく Web サービスだ。サービスを使うとリモートへのバックアップに加え、変更提案をやり取りするプルリクエスト、課題管理、自動テストといった機能が付いてくる。
ただし繰り返しになるが、これらは必須ではない。まずはローカルでの commit に習熟し、共有が必要になった段階で git remote add や git clone を通じてサービスを足していく、という流れが堅実だ。