【新入社員のための実践ガイド】チーム開発で困らないGitの使い方

はじめに

最近、GitHub Copilot や Claude Code を使って開発することが増えてきました。

• コードを書いてくれる
• commit してくれる
• PR まで作ってくれる

こういったことが普通にできてしまうので、
コマンドやコードを理解したつもりになっていることが増えた気がします。

今回は、自分の整理も兼ねてまとめてみます。

Git の基本的な流れを整理する

Git を使った変更の共有は、大きく 3 ステップです。

git add     # 変更を選ぶ（ステージング）
git commit  # 変更を記録する
git push    # リモートに共有する
git add     # 変更を選ぶ（ステージング）
git commit  # 変更を記録する
git push    # リモートに共有する

add・commit・push の違いをざっくり理解する

コマンドやることイメージ

git add

次のコミットに含める変更を選ぶ

荷物をダンボールに入れる

git commit

変更を歴史として記録する

ダンボールにラベルを貼って封をする

git push

GitHub などのリモートに送る

宅配業者に渡す

補足： git add した段階ではまだ「記録」はされていません。git commit して初めて履歴として残ります。

リモートとローカルの違いをまず整理する

Git を理解するうえで、最初につまずきやすいのがリモートとローカルの概念です。

場所意味

リモート（remote）

GitHub などのサーバー上にあるリポジトリ。チームで共有する場所

ローカル（local）

自分の PC 上にあるリポジトリ。自分だけが触れる作業場所

チーム開発では最初に git clone でリモートのリポジトリをローカルにコピーするところから始まります。

git clone https://github.com/your-org/your-repo.git
git clone https://github.com/your-org/your-repo.git

これ以降、作業はすべてローカルで行い、完成したらリモートに push するという流れになります。

全体の流れ

【リモート（GitHub）】
  main ブランチ（チームの共有ベースライン）
       │
       │ git clone（最初の1回）
       │ git fetch（リモートの変更を確認するとき）
       │ git pull（リモートの変更を取り込むとき）
       ▼
【ローカル（自分の PC）】
  main ブランチ
       │
       │ git checkout -b（作業ブランチを作る）
       ▼
  feature/user-login（ここで作業する）
       │
       │ git push（作業をリモートに送る）
       ▼
【リモート（GitHub）】
  feature/user-login ブランチ
       │
       │ Pull Request → レビュー → マージ
       ▼
  main ブランチ（更新される）
【リモート（GitHub）】
  main ブランチ（チームの共有ベースライン）
       │
       │ git clone（最初の1回）
       │ git fetch（リモートの変更を確認するとき）
       │ git pull（リモートの変更を取り込むとき）
       ▼
【ローカル（自分の PC）】
  main ブランチ
       │
       │ git checkout -b（作業ブランチを作る）
       ▼
  feature/user-login（ここで作業する）
       │
       │ git push（作業をリモートに送る）
       ▼
【リモート（GitHub）】
  feature/user-login ブランチ
       │
       │ Pull Request → レビュー → マージ
       ▼
  main ブランチ（更新される）

重要： プロジェクトによっては main → staging → production のように複数環境を使い分けるケースもあります。ただ、「チームで共有する一番大事なブランチ」という意味では main を起点に考えると理解しやすいです。

ブランチとは何か

Git にはブランチという仕組みがあります。

ブランチ = 作業用の独立した歴史の流れ だと思うとイメージしやすいです。

main ブランチはチームみんなが使う共有のベースラインです。
そこに直接変更を加えると、レビューなしで変更が共有されてしまい、バグが混入しても気づきにくくなります。

なので、開発するときは別のブランチを切って（作って）作業し、PR 経由でレビューしてから main にマージ（合流）するという流れが一般的です。

main（チームの共有ベースライン）
  │
  ├─ feature/user-login（ログイン機能の作業ブランチ）
  │      ↓ PR → レビュー → main にマージ
  └─ feature/password-reset（パスワードリセットの作業ブランチ）
         ↓ PR → レビュー → main にマージ
main（チームの共有ベースライン）
  │
  ├─ feature/user-login（ログイン機能の作業ブランチ）
  │      ↓ PR → レビュー → main にマージ
  └─ feature/password-reset（パスワードリセットの作業ブランチ）
         ↓ PR → レビュー → main にマージ

操作方法 ① コマンドでやる

最新状態を取り込む（作業前に必ずやる）

作業を始める前に、リモートの最新状態をローカルに取り込みます。
これをサボると、他のメンバーの変更が入っていない古い状態からブランチを作ることになり、後でコンフリクトが増えます。

ここで出てくるのが git fetch と git pull です。

git fetch と git pull の違い

コマンドやることローカルへの影響

git fetch

リモートの変更情報をダウンロードする

ローカルのファイルは変わらない

git pull

fetch ＋ ローカルに自動でマージする

ローカルのファイルが更新される

git pull は git fetch + git merge を一度にやってくれるコマンドです。

# 下の 2 行と
git fetch origin
git merge origin/main

# これは同じ意味
git pull origin main
# 下の 2 行と
git fetch origin
git merge origin/main

# これは同じ意味
git pull origin main

どちらを使えばいいのか

慣れないうちは git pull で問題ありません。
ただ、「リモートに何が来ているか確認してからマージしたい」というときは git fetch が便利です。

# リモートの変更を確認だけする（ファイルは変わらない）
git fetch origin

# どんな変更が来ているか見る
git log HEAD..origin/main --oneline

# 問題なければ取り込む
git merge origin/main
# リモートの変更を確認だけする（ファイルは変わらない）
git fetch origin

# どんな変更が来ているか見る
git log HEAD..origin/main --oneline

# 問題なければ取り込む
git merge origin/main

fetch が役立つ場面： 大きな変更が来ていそうなとき、コンフリクトが起きそうか事前に確認したいときなど。「見てから判断する」のが fetch、「とりあえず最新にする」のが pull、という使い分けが多いです。

実際の作業前の流れ

# ローカルの main ブランチに移動
git checkout main

# リモートの最新を取り込む
git pull origin main
# ローカルの main ブランチに移動
git checkout main

# リモートの最新を取り込む
git pull origin main

ブランチを切る（作業ブランチを作る）

最新の main から作業ブランチを作ります。

# 新しいブランチを作って、そのブランチに移動する
git checkout -b feature/user-login

# 現在のブランチを確認する
git branch
# 新しいブランチを作って、そのブランチに移動する
git checkout -b feature/user-login

# 現在のブランチを確認する
git branch

git checkout -b <ブランチ名> で「新しいブランチを作る＋そこに移動する」が同時にできます。

ブランチ名はあとから見てわかるように feature/機能名 や fix/バグ内容 のように書くと親切です。

補足： Git 2.23 以降は git switch -c feature/user-login という書き方もできます。どちらでも動作は同じです。

変更を確認する

git status  # どのファイルが変更されたか確認
git diff    # 具体的に何が変わったか確認（行単位）
git status  # どのファイルが変更されたか確認
git diff    # 具体的に何が変わったか確認（行単位）

git status はざっくり「何が変わったか」、git diff は「どの行がどう変わったか」を教えてくれます。

最初は飛ばしがちですが、ここが一番大事です。
add する前に差分を確認する習慣をつけると、意図しないファイルを commit するミスが減ります。

add する（記録対象を選ぶ）

特定のファイルだけ追加する場合：

git add app/models/user.rb
git add app/models/user.rb

全ファイルを追加する場合：

git add .
git add .

git add . はカレントディレクトリ以下の変更をすべてステージングします。
開発中の途中ファイルや、commit したくない変更まで含まれてしまうことがあるので、最初のうちはファイルを指定する方法に慣れると安心です。

commit する（変更を記録する）

git commit -m "ユーザー登録のバリデーション修正"
git commit -m "ユーザー登録のバリデーション修正"

commit メッセージは「あとから見たときに何をしたかわかる」ように書くのがポイントです。

悪い例良い例

fix

ユーザー登録のバリデーション修正

update

パスワードの最小文字数を 6 文字から 8 文字に変更

作業中

ログイン画面のレイアウト崩れを修正

commit は小さく、メッセージは具体的に。
後でバグが起きたとき、「どの commit で壊れたか」を探すのに役立ちます。

push する（GitHub に反映する）

git push origin feature/user-login
git push origin feature/user-login

origin はリモートリポジトリ（GitHub）の名前、その後ろが push 先のブランチ名です。

補足： 初回 push 時に git push -u origin feature/user-login とすると、次回から git push だけで同じブランチに push できるようになります。

マージする（変更を main に取り込む）

作業ブランチの内容を main ブランチに取り込む操作がマージです。

# main ブランチに移動する
git checkout main

# 最新の状態を取得する
git pull origin main

# 作業ブランチの変更を取り込む
git merge feature/user-login
# main ブランチに移動する
git checkout main

# 最新の状態を取得する
git pull origin main

# 作業ブランチの変更を取り込む
git merge feature/user-login

ただし、実際の開発現場ではコマンドで直接マージすることはほとんどなく、GitHub の Pull Request（PR）経由でマージするのが一般的です。

Pull Request の流れ

1. 作業ブランチを push する
2. GitHub 上で Pull Request を作成する
3. チームメンバーにレビューしてもらう
4. 承認されたら main にマージする

PR を使うことで、他の人にコードを確認してもらってからマージできるので、バグやミスの混入を防ぎやすくなります。

コンフリクト（競合）が起きたら

複数人が同じファイルの同じ行を編集すると、マージ時にコンフリクト（競合）が発生することがあります。

<<<<<<< HEAD
本文（自分の変更）
=======
本文（相手の変更）
>>>>>>> feature/user-login
<<<<<<< HEAD
本文（自分の変更）
=======
本文（相手の変更）
>>>>>>> feature/user-login

このようなマークが入ったファイルを手動で編集して、どちらの変更を採用するかを決めて再度 commit します。

コンフリクトは焦らずに！どちらの変更が正しいかをチームで確認しながら解決するのが基本です。

操作方法 ② VSCode でやる

VSCode は Git の操作を GUI で行える機能が最初から備わっています。

セットアップ（事前に必要な設定）

GUI でコミット・プッシュするには、VSCode の設定より先に Git 本体の設定 が必要です。
ここを飛ばすとコミットできなかったり、push 時に認証エラーになります。

① Git のユーザー情報を設定する

コミットには「誰がコミットしたか」の情報が必要です。
ターミナルで一度だけ実行しておきます。

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

メールアドレスは GitHub に登録しているものと同じにしておくと、コミットが GitHub アカウントと紐づきます。

設定できているか確認するには：

git config --global --list
git config --global --list

② GitHub の認証設定をする（push に必要）

ローカルから GitHub に push するには、GitHub に「自分が誰か」を証明する認証が必要です。
方法はいくつかありますが、GitHub CLI が一番簡単でおすすめです。

方法 A：GitHub CLI（おすすめ）

# GitHub CLI をインストール（Mac の場合）
brew install gh
 
# 認証（ブラウザが開いてログインするだけ）
gh auth login
# GitHub CLI をインストール（Mac の場合）
brew install gh
 
# 認証（ブラウザが開いてログインするだけ）
gh auth login

Windows の場合は GitHub CLI の公式ページ からインストーラーをダウンロードできます。

方法 B：SSH キーを設定する

# SSH キーを生成
ssh-keygen -t ed25519 -C "you@example.com"
 
# 公開鍵を表示してコピー
cat ~/.ssh/id_ed25519.pub
# SSH キーを生成
ssh-keygen -t ed25519 -C "you@example.com"
 
# 公開鍵を表示してコピー
cat ~/.ssh/id_ed25519.pub

コピーした公開鍵を GitHub の「Settings → SSH and GPG keys」に登録します。

方法 C：Personal Access Token（PAT）

GitHub の「Settings → Developer settings → Personal access tokens」からトークンを発行し、push 時のパスワードとして使います。
ただし管理が手間なので、慣れないうちは GitHub CLI の方が楽です。

VSCode の場合： VSCode 拡張の「GitHub Pull Requests」などを入れると、VSCode 内から GitHub 認証を一括でセットアップできる場合もあります。

VSCode はリポジトリを開くと自動的に Git を検出します。

Git がインストールされていない場合は git-scm.com からインストールしてください。

ソース管理タブでの基本操作

左のサイドバーにある「ソース管理」アイコン（Ctrl+Shift+G）を開くと、変更ファイルが一覧で表示されます。

■操作やり方

add（ステージング）：ファイル横の「＋」をクリック
commit：メッセージを入力して「✓ コミット」をクリック
push：「変更の同期」または「…」メニューから「プッシュ」
ブランチ切り替え：左下のブランチ名をクリック → ブランチを選択または新規作成

ブランチ操作を VSCode でやる

左下のステータスバーに現在のブランチ名が表示されています。

• クリック → ブランチの一覧が出る
• 「新しいブランチを作成...」を選択 → ブランチ名を入力 → Enter

これだけで git checkout -b と同じことができます。

diff（差分）を GUI で確認する

ソース管理タブでファイルをクリックすると、変更前後の diff が横並びで表示されます。
コマンドの git diff より視覚的にわかりやすいので、最初はこちらから確認する習慣をつけると理解しやすいです。

コンフリクトの解決も VSCode でできる

VSCode はコンフリクトが発生すると、該当箇所に「現在の変更を取り込む」「受信した変更を取り込む」「両方取り込む」などのボタンを表示してくれます。
手動でマークを消す必要がなく、直感的に解決できます。

便利な拡張機能

• GitLens：誰がいつどの行を変更したか（blame 情報）をコード上で確認できる
• Git History：ブランチの commit 履歴をグラフ形式で可視化できる

コマンドとやっていることはまったく同じです。「コマンドに慣れていない」場合はここから始めると理解しやすいと思います。

操作方法 ③ Claude Code でやる

Claude Code を使うと、自然言語で Git 操作を依頼できます。

変更をコミットして
変更をコミットして

と伝えるだけで、

• 差分の確認
• add
• commit（メッセージも生成してくれる）
• push

までやってくれます。

Claude Code がやってくれること

• commit メッセージの自動生成： 変更内容をもとに適切なメッセージを書いてくれる
• 変更内容の説明： 「このファイルのこの部分を変更しました」と説明してくれる
• commit 前に確認： 実行前に「これでいいですか？」と聞いてくれる
• ブランチ操作： 「新しいブランチを切って作業して」と依頼できる
• PR の作成： GitHub CLI と連携して PR 作成まで対応してくれる

CLAUDE.md（プロジェクトのルールを AI に教える）

Claude Code には CLAUDE.md というファイルをプロジェクトルートに置くと、そこに書いた内容を Claude Code が毎回参照してくれる機能があります。

これは Claude Code の「Skills（スキル）」とも呼ばれ、プロジェクト固有のルールや手順を AI に覚えさせることができます。

たとえばこんな内容を書いておくと便利です：

# CLAUDE.md

## プロジェクト概要
- Ruby on Rails + React のアプリです

## コーディングルール
- commit メッセージは日本語で書く
- ブランチ名は feature/機能名 の形式にする

## よく使うコマンド
- テスト実行: bundle exec rspec
- サーバー起動: bin/dev
# CLAUDE.md

## プロジェクト概要
- Ruby on Rails + React のアプリです

## コーディングルール
- commit メッセージは日本語で書く
- ブランチ名は feature/機能名 の形式にする

## よく使うコマンド
- テスト実行: bundle exec rspec
- サーバー起動: bin/dev

こうしておくと、Claude Code が「このプロジェクトでは commit メッセージを日本語で書く」というルールを把握した上で作業してくれます。

チームで開発する場合は、CLAUDE.md をリポジトリに含めておくことで、メンバー全員が同じルールで AI を使えるようになります。

補足： CLAUDE.md はあくまで Claude Code への指示書です。書いた内容が自動的に実行されるわけではなく、Claude Code が作業するときの参考情報として使われます。

個人開発でやりがちだけど、チーム開発では気をつけること

個人開発だと「動けばいいか」で済みますが、チームに入ると困るパターンがあります。
自分が実際にやってしまっていたことも含めてまとめます。

① main に直接 commit・push する

# ❌ やりがちな個人開発の流れ
git add .
git commit -m "修正"
git push origin main
# ❌ やりがちな個人開発の流れ
git add .
git commit -m "修正"
git push origin main

個人開発では誰も困らないので気づきにくいですが、チーム開発では main を直接変更するとレビューなしで全員に影響が出るため NG です。

ブランチを切って PR を出す習慣を先につけておくと安心です。

② git pull を忘れて作業を始める

他のメンバーが main を更新していても、git pull しないと古い状態から作業することになります。
後でコンフリクトが増えたり、「自分の変更が消えた！？」という混乱につながります。

作業前の git pull はセットと覚えておくといいです。

③ git add . で全部まとめて commit する

個人開発では「全部自分の変更だし問題ない」と思いがちです。
でもチームでは commit の粒度がそのままレビューの読みやすさに直結します。

関係ない変更が混ざった commit はレビュアーが困ります。

# ❌ 全部まとめて
git add .
git commit -m "いろいろ修正"

# ✅ 変更の意味ごとに分ける
git add app/models/user.rb
git commit -m "ユーザーモデルのバリデーション追加"

git add app/controllers/users_controller.rb
git commit -m "ユーザー登録時のエラーハンドリング追加"
# ❌ 全部まとめて
git add .
git commit -m "いろいろ修正"

# ✅ 変更の意味ごとに分ける
git add app/models/user.rb
git commit -m "ユーザーモデルのバリデーション追加"

git add app/controllers/users_controller.rb
git commit -m "ユーザー登録時のエラーハンドリング追加"

④ commit メッセージが雑

個人開発なら「後でわかるからいいか」で済みますが、チームでは他のメンバーが git log を見て作業内容を把握します。

# ❌ 後から何もわからない
git commit -m "fix"
git commit -m "修正"
git commit -m "テスト"

# ✅ 何をしたか一目でわかる
git commit -m "ログイン失敗時のエラーメッセージを日本語に修正"
# ❌ 後から何もわからない
git commit -m "fix"
git commit -m "修正"
git commit -m "テスト"

# ✅ 何をしたか一目でわかる
git commit -m "ログイン失敗時のエラーメッセージを日本語に修正"

⑤ 1 つのブランチでいろんな作業をする

「ログイン機能を作りながらついでにヘッダーも直した」というケースです。
関係のない変更が同じブランチに混在すると、PR のレビューが大変になります。

作業の単位でブランチを分ける習慣をつけると、後々楽になります。

⑥ 長期間 main から更新を取り込まない

自分のブランチで長く作業していると、main との差分がどんどん広がっていきます。
いざマージしようとしたときに大量のコンフリクトが発生して解決が大変になります。

こまめに git pull origin main してブランチに取り込む（または git rebase main）と、差分を小さく保てます。

# 自分のブランチで main の最新を取り込む
git fetch origin
git merge origin/main
# または
git rebase origin/main
# 自分のブランチで main の最新を取り込む
git fetch origin
git merge origin/main
# または
git rebase origin/main

merge と rebase はどちらも「他のブランチの変更を取り込む」操作ですが、履歴の見え方が変わります。チームのルールに合わせて使いましょう。

じゃあ全部 AI に任せていいのか？

「これで全部解決じゃん」と最初は思いました。

でも振り返ると、自分の使い方にちょっと問題がありました。

自分がやってしまっていたこと

• diff をちゃんと見ていない
• Claude Code が生成した commit メッセージをそのまま OK していた
• 複数の変更がまとまって 1 commit になっていた
• main ブランチに直接作業していた（ブランチを切っていなかった）

つまり、「確認している気になっているだけで、内容をほとんど把握していない」 という状態でした。

一番気になったのは commit 履歴

Git の大事な役割のひとつは「いつ・誰が・何を変更したかを履歴として残す」ことです。

AI に任せっぱなしにしていると、

• 複数の変更が 1 commit にまとまる
• メッセージがざっくりしすぎていて後でわからない

という状態になりがちです。

たとえば：

git log --oneline

a1b2c3d fix
e4f5g6h update
git log --oneline

a1b2c3d fix
e4f5g6h update

後から「何を直したんだっけ…？」となります。

AI と Git の役割は違う

整理するとこういうことだと思います。

役割

AI（Claude Code など）

作業を速くする・コードを生成する

Git

変更の履歴を意味のある形で残す

AI が作業を速くしてくれるからこそ、「何を・なぜ変更したか」を人間が意識して記録する ことが重要になります。

今気をつけていること

私は現在個人開発を行っており、まだ模索中ですが、意識していることを共有します。

• 作業前にブランチを切る（main に直接 commit しない）
• git diff で差分を確認してから add する
• git add . ではなくファイル単位で add する
• commit は変更の単位でこまめに分ける
• commit メッセージは「何をなぜ変えたか」が伝わるように書く
• AI が生成した commit メッセージをそのまま使わず、内容を確認してから採用する
• CLAUDE.md にプロジェクトのルールを書いておく

まとめ

AI のおかげで開発のスピードは確実に上がりました。

ただ、Git に関しては

• 操作は AI に任せられる
• でも「何をどう記録するか」は自分で考える必要がある
• ブランチを切る・PR を出す・コンフリクトを解決するといった流れは理解しておいた方がいい
• 個人開発で雑にやってたクセは、チーム開発では早めに直しておいた方がいい

と感じています。

「なんとなく使ってるかも」という方の参考になれば嬉しいです。