リモートと同期（remote / push / pull）
手元のリポジトリと、GitHubなどサーバー上のリポジトリ（リモート）をやり取りすると、他の人と変更を共有できます。リモートの登録状況は git remote で確認し、手元のコミットを送り出すのが git push、サーバー側の変更を取り込むのが git pull です。一般に既定のリモートは origin という名前で登録されます。チーム開発では push の前に pull で最新を取り込む流れが基本になります。
ここまでは自分の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 pull が「取ってきて手元に合流まで」やるのに対し、git fetch は「取ってくるだけで、手元にはまだ合流しない」操作です。fetch した後は origin/main のような名前で「サーバー側の最新がどこまで来ているか」を確認でき、内容を見てから自分のタイミングで git merge して合流させられます。サーバー側に何が来ているかを先に確かめてから取り込みたいときに、この使い分けが効いてきます。慣れないうちは pull だけでも実務は回りますが、fetch という安全側の選択肢があることは知っておくと役立ちます。
共同作業の基本リズムとつまずきやすい点
チームで1つのリモートを共有して開発するときの基本リズムは、「push の前にまず pull」です。自分が作業している間に、他の人が先にサーバーへ変更を送っているかもしれません。その状態でいきなり push しようとすると、サーバー側のほうが進んでいるために push が拒否されます。これは Git が「あなたはまだ取り込んでいない他人の変更があるので、上書きさせません」と守ってくれているのです。このときは、まず git pull で相手の変更を取り込み、必要ならコンフリクトを解決してから、あらためて git push します。この「pull してから push」を習慣にすると、共同作業での衝突をかなり防げます。なお、pull しようとしたときに手元で中途半端な編集が残っていると、合流の邪魔になって警告が出ることがあります。そんなときは git stash で編集を一時的に棚へ退避し、pull を済ませてから git stash pop で戻す、という手順が役立ちます。
認証とサービスについての補足
最初に push するとき、本人確認のための認証を求められます。HTTPS の URL を使う場合、いまはパスワードの代わりにアクセストークンと呼ばれる文字列を使うのが主流です。具体的な発行手順や認証方法はサービスや環境ごとに異なるため、画面の案内に従ってください。なお、ここで混同しやすいのが Git と GitHub の関係です。Git は手元で動くバージョン管理の道具そのもので、GitHub や GitLab は、その Git リポジトリを置いておく Web サービスです。両者は別物で、サービスを使うとリモートへのバックアップに加え、変更提案をやり取りするプルリクエスト、課題管理、自動テストといった機能が付いてきます。ただし繰り返しになりますが、これらは必須ではありません。まずはローカルでの commit に習熟し、共有が必要になった段階で git remote add や git clone を通じてサービスを足していく、という流れが堅実です。