Git のリモートと PR 運用：push・pull・GitHub でチーム開発する

前回まででローカル上のコミット・ブランチ・rebase・コンフリクト解消と、Git の主要操作を一通り学んできました。しかしこれらはすべて「自分のマシン上での作業」です。チーム開発で真価を発揮するのは、変更を共有するリモートリポジトリとのやり取りです。

リモートリポジトリとは

リモートリポジトリとは、インターネット上（またはLAN上）のサーバーに置かれた、チームで共有する Git リポジトリのことです。自分のマシン上にある「ローカルリポジトリ」に対して、外部にある共有の置き場をリモートリポジトリと呼びます。

代表的なホスティングサービスが GitHub（ギットハブ）です。 Git リポジトリをクラウドで管理できるサービスで、コードレビューや Issues・プルリクエストなどの機能を備えています。他に GitLab や Bitbucket もありますが、本記事では GitHub を前提に説明します。

ローカルとリモートの関係は次のようなイメージです。

ローカル（自分のPC）          リモート（GitHub 等）
┌──────────────────┐   push  ┌──────────────────┐
│  ローカルリポジトリ │ ──────> │ リモートリポジトリ  │
│  （作業・コミット） │ <────── │  （チームで共有）   │
└──────────────────┘  pull   └──────────────────┘

リモートの登録と確認

git remote add

ローカルリポジトリに対してリモートを登録するコマンドが git remote add です。

git remote add origin https://github.com/yourname/your-repo.git

慣習として最初のリモートには origin という名前をつけます。 origin は単なるエイリアスで、長い URL を毎回打たなくて済むようにしているだけです。

登録後に git remote -v で確認します。

git remote -v
# origin  https://github.com/yourname/your-repo.git (fetch)
# origin  https://github.com/yourname/your-repo.git (push)

fetch（取得）と push（送信）それぞれの URL が表示されます。通常は同じ URL です。

git clone

既存のリポジトリを手元に持ってくる場合は git clone を使います。 git remote add から手動でセットアップする必要はなく、クローンすれば origin の登録も自動で完了します。

git clone https://github.com/yourname/your-repo.git
cd your-repo

ディレクトリ名を変えたい場合は末尾に指定します。

git clone https://github.com/yourname/your-repo.git myproject

初回 push と上流ブランチの設定

ローカルでコミットを積んだら、リモートに送信します。

git push -u origin main

-u オプション（--set-upstream の略）がポイントです。これを一度実行すると、ローカルの main ブランチと origin/main が紐付けられ（上流ブランチの設定）、以降は git push と打つだけで同じ宛先に送れるようになります。

2回目以降は短く済みます。

git push
# -u で登録済みなので origin main は省略できる

fetch と pull の違い

リモートの最新状態を取得するコマンドが git fetch と git pull の2つあります。混同しやすいので整理します。

git fetch: リモートの変更をダウンロードするだけ。ローカルの作業ブランチには影響しない。

git fetch origin
# origin の最新を取得し origin/main 等のリモート追跡ブランチを更新する
# 作業中の main ブランチはそのまま

git pull: fetch + merge（または rebase）を一度に行う。ローカルブランチを更新する。

git pull
# 内部的に git fetch → git merge origin/main が走る

個人的には git fetch を先に実行して差分を確認してから統合するほうが安全です。「知らないうちにマージが走った」という事態を避けられます。

git fetch origin
git diff main origin/main    # ローカルとリモートの差分を確認
git merge origin/main        # 問題なければ統合

git pull —rebase

前回（#3）で学んだ rebase を pull にも適用できます。

git pull --rebase

通常の git pull はマージコミットを作りますが、--rebase を付けるとリモートの変更をベースにローカルのコミットが積み直されます。履歴が直線的になり、git log が読みやすくなるため、チームで推奨されることが多い設定です。

常に rebase で pull したい場合は設定で固定できます。

git config --global pull.rebase true

プルリクエスト（PR）の運用フロー

GitHub を使うチーム開発では、変更を直接 main に push するのではなく、フィーチャーブランチを作って PR（プルリクエスト）を出すのが一般的なフローです。

PR はレビューを経てからマージする仕組みで、コードの品質担保とナレッジ共有の両方に機能します。

典型的な流れは次の通りです。

1. フィーチャーブランチを作って作業する

git switch -c feature/add-login
# コード変更 → コミット
git add .
git commit -m "feat: ログイン機能を追加"

2. フィーチャーブランチを push する

git push -u origin feature/add-login

3. GitHub 上で PR を作成する

push 後に GitHub を開くと「Compare & pull request」ボタンが表示されます。タイトルと説明を書いて PR を作成します。説明には「何を・なぜ変えたか」「どう動作確認したか」を書くと、レビュアーが判断しやすくなります。

4. レビュー → 修正 → マージ

レビュアーからコメントが付いたら、ローカルで修正してコミットを追加し、同じブランチに push します。 PR は自動的に更新されます。

# レビュー指摘を修正してプッシュ
git commit -m "fix: バリデーションを修正"
git push

承認を得たら、GitHub 上の「Merge pull request」ボタンでマージします。マージ後はフィーチャーブランチを削除してクリーンな状態を保ちます。

# マージ後にローカルのブランチも削除
git switch main
git pull
git branch -d feature/add-login

認証について

GitHub にアクセスするには認証が必要です。主な方法は2つあります。

HTTPS + Personal Access Token（PAT）

GitHub の設定画面（Settings → Developer settings → Personal access tokens）でトークンを発行し、push 時に ID の代わりに使います。パスワードを直接使う認証は廃止されており、現在は PAT が必要です。

SSH 鍵認証

公開鍵をGitHubアカウントに登録し、SSH プロトコルで接続します。 PAT のようにトークンの有効期限を気にしなくてよく、接続も安定しています。 SSH 鍵の生成と管理については、連載「Linux 実践入門」#8 で詳しく解説しているので参考にしてください。

SSH 鍵を登録済みなら、リモート URL を SSH 形式に変更して使います。

git remote set-url origin git@github.com:yourname/your-repo.git

実践的なコツ

push 前に pull して差分を取り込む

push する前に git fetch + git rebase origin/main（または git pull --rebase）を習慣にすると、リモートとローカルの乖離を小さく保てます。コンフリクトが起きても早い段階で小さな差分として対処できます。

PR は小さく保つ

1つのPRに大量の変更を詰め込むとレビューが重くなり、バグの見落としも増えます。機能単位・ファイル単位で細かく分けるほど、レビューの品質と速度が上がります。「レビュアーに30分で読み切れる量か」を目安にすると判断しやすいです。

ブランチ名の付け方

ブランチ名はチームで規則を統一しておくと管理しやすくなります。よく使われる形式：

feature/機能名（新機能）
fix/バグ名 または bugfix/issue番号（バグ修正）
chore/タスク名（リファクタリング・設定変更など）
docs/ドキュメント名（ドキュメント修正）

GitHub では PR のタイトルとブランチ名が並んで表示されるため、一目で内容がわかる名前にしておくと後から履歴を追いやすくなります。

まとめ

リモートリポジトリは GitHub 等のサーバー上の共有リポジトリ。git remote add origin <URL> で登録する
初回 push は git push -u origin main。-u で上流ブランチを設定し、以降は git push だけでよくなる
git clone <URL> で既存リポジトリを手元に持ってこられる。origin も自動設定される
git fetch はダウンロードのみ・作業ブランチに影響しない。git pull は fetch + merge を一度に行う
git pull --rebase を使うと履歴が直線的になり読みやすい
PR 運用の基本：フィーチャーブランチを push → GitHub で PR 作成 → レビュー → マージ → ブランチ削除
push 前に pull、PR は小さく、ブランチ名はチームで統一する

これで連載「Git 実践入門」は完結です。 5回を通じて、Git の核となる知識を一通り学びました。

#1 基本操作：git init / git add / git commit / git log でバージョン管理の出発点を作った
#2 ブランチ：git switch -c でブランチを切り、git merge で統合する並行開発の基本
#3 rebase：コミット履歴を整理する git rebase と、インタラクティブrebaseによるコミット編集
#4 コンフリクト：コンフリクトマーカーの読み方、merge / rebase それぞれの解消手順
#5 リモートと PR：git push / git pull / git fetch を使ったリモート連携と、GitHub PR フロー

ローカルでの履歴管理からリモートでのチーム開発まで、実務でよく使うパターンをカバーしました。あとは実際のプロジェクトで手を動かすことで定着します。最初は git status と git log --oneline を頻繁に確認しながら進めるのがコツです。