リモートリポジトリとコラボレーション
GitHub との連携、push/pull の操作、チーム開発のワークフローを演習問題で学びます。
このチュートリアルでは、リモートリポジトリ(GitHub など)との連携方法を演習形式で学びます。チーム開発での基本的なワークフローを体験します。
前提: GitHub アカウントを持っていることを推奨します。GitHub なしでも概念の理解はできますが、push/pull 操作は実際のリモートリポジトリが必要です。
リモートリポジトリとは
リモートリポジトリとは、インターネット上(または社内サーバー上)に置かれた Git リポジトリです。
ローカル(自分のPC) リモート(GitHub等)
┌──────────────┐ ┌──────────────────┐
│ .git/ │ git push → │ リポジトリ │
│ 作業ツリー │ ← git pull │ (共有) │
└──────────────┘ └──────────────────┘
複数人が同じリモートリポジトリを通じてコードを共有します。
演習 1:リモートリポジトリを追加する
GitHub で新しいリポジトリを作成し、ローカルに接続してください。
前提操作: GitHub で空のリポジトリ(例: git-practice)を作成しておきます。
問題: ローカルリポジトリに origin という名前でリモートを追加するコマンドを書いてください。
答えを見る
git remote add origin https://github.com/ユーザー名/git-practice.git追加後、確認するには:
git remote -v
# origin https://github.com/ユーザー名/git-practice.git (fetch)
# origin https://github.com/ユーザー名/git-practice.git (push)origin はリモートリポジトリの一般的な別名(エイリアス)です。
演習 2:リモートに初回プッシュする
ローカルの main ブランチをリモートの main ブランチにプッシュしてください。
問題: リモートを追跡(トラッキング)設定しながら main ブランチをプッシュするコマンドを書いてください。
答えを見る
git push -u origin main-u(--set-upstream)を付けることで、次回以降は git push だけで同じリモートにプッシュできます。
出力例:
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Branch 'main' set up to track remote branch 'main' from 'origin'.
To https://github.com/ユーザー名/git-practice.git
* [new branch] main -> main演習 3:フィーチャーブランチで開発してプッシュする
新機能ブランチを作成して開発し、リモートにプッシュしてください。
問題: feature/about ブランチを作成し、about.txt ファイルを追加してコミット後、リモートにプッシュしてください。
答えを見る
# ブランチを作成して切り替え
git switch -c feature/about
# ファイルを追加
echo "これは練習用リポジトリです。" > about.txt
git add about.txt
git commit -m "about.txt を追加"
# リモートにプッシュ
git push -u origin feature/aboutGitHub 上でブランチが作成されたことを確認できます。
演習 4:リモートの変更を取得する
別の人がリモートに変更をプッシュしたとします。その変更をローカルに取り込んでください。
概念の確認: 以下の2つのコマンドの違いを説明してください。
git fetchgit pull
答えを見る
| コマンド | 動作 |
|---|---|
git fetch | リモートの変更情報を取得するが、作業ツリーは変更しない。確認してからマージできる。 |
git pull | git fetch + git merge を連続実行。リモートの変更をそのままローカルに取り込む。 |
# fetch して内容を確認してからマージ
git fetch origin
git log origin/main..HEAD # ローカルにあってリモートにないコミットを確認
git merge origin/main
# または一括で
git pull origin main作業中に予期しないマージを避けたい場合は git fetch を先に使うのが安全です。
演習 5:プルリクエストの基本フロー
GitHub でのプルリクエスト(PR)ベースの開発フローを理解してください。
問題: フィーチャーブランチの変更を main に取り込む、GitHub での一般的な手順を順番に並べてください。
- フィーチャーブランチで開発・コミット
- レビュアーがコードをレビューする
mainブランチをフィーチャーブランチにマージする- GitHub でプルリクエストを作成する
- フィーチャーブランチをリモートにプッシュする
- 承認後、
mainにマージする - 必要に応じてフィーチャーブランチを削除する
答えを見る
正しい順番:
- フィーチャーブランチで開発・コミット
- フィーチャーブランチをリモートにプッシュする
- GitHub でプルリクエストを作成する
- レビュアーがコードをレビューする
- 承認後、
mainにマージする - 必要に応じてフィーチャーブランチを削除する
# ローカルでのクリーンアップ
git switch main
git pull
git branch -d feature/about演習 6:コンフリクトを含む pull の解決
リモートの main に変更があり、自分のローカルでも同じファイルを変更した場合の解決方法を練習します。
# まずリモートの状態を取得
git fetch origin
# 差分を確認
git diff main origin/main
# rebase で取り込む(履歴が直線的になる)
git pull --rebase origin main
rebase 中にコンフリクトが発生したら:
# 1. ファイルを編集してコンフリクトを解決
# 2. ステージングして続行
git add <conflicted-file>
git rebase --continue
# やり直したい場合
git rebase --abort
まとめ
チーム開発の基本フロー:
1. git pull ← 最新を取得
2. git switch -c feature/xxx ← ブランチを作成
3. 開発・コミット
4. git push -u origin feature/xxx ← リモートにプッシュ
5. GitHub でプルリクエスト作成
6. レビュー → マージ
7. git pull ← main を最新に
8. git branch -d feature/xxx ← ブランチを削除
このフローを繰り返すことで、安全で整理されたチーム開発ができます。