この章で学ぶこと
推定読了時間: 20-30分 | 難易度: ★★☆☆☆
本書は「Why Git?」シリーズの第2巻です。
「Why Git?」——AI時代になぜGitが必要なのか。GitHub CopilotやClaude CodeといったAIツールがコードを生成してくれる今、Gitの重要性はむしろ高まっています。AIが生成したコードを安全に管理し、チームで共有し、品質を保証する。その土台となるのがGitのしくみです。
基礎編（Vol. I）では、一人でバージョン管理ができるようになりました。コミットを作成し、ブランチを切り替え、マージもできるようになったはずです。Gitの基本コマンドや概念を一から学びたい方は、まず基礎編から読むことをおすすめします。
しかし、実際の開発現場では一人で開発することは稀です。チームでコードを共有したい。複数人で同時に開発したい。コードレビューを受けて品質を高めたい。そんな場面で、ローカルだけのGit操作では限界があります。
本書「Why Git? Vol. II：マスター編」では、チーム開発で活躍するためのGitスキルを学びます。リモートリポジトリとの連携、コンフリクトの解決、Pull Requestを使ったコードレビュー、AIツールとの連携、CI/CDによる自動化——これらは現代の開発現場で日常的に使われている実践的なスキルです。
本書の内容をマスターすれば、プロの開発チームに参加する準備が整います。「Gitがよく分からなくて不安」という気持ちは、「Gitなら任せてください」という自信に変わるはずです。
YouTubeやブログ、Q&Aサイトなど、GitやAI開発について無料で学べる情報は今やいくらでもあります。それ自体はすばらしいことです。ただ、これらの情報源にはそれぞれ得意・不得意があります。
動画コンテンツは特定のテーマをわかりやすく紹介してくれますが、1本の動画で扱えるのはどうしても断片的な内容になります。「git pushのやり方」「コンフリクトの解消法」といった個々のトピックはカバーされていても、それらがどうつながるのか、現場ではどういう順番で使うのかという全体像はなかなか見えてきません。
ネット上の記事も同様です。検索すれば答えは見つかりますが、そもそも何を検索すればいいのかわからないのが初心者の壁です。「git worktreeとAIエージェントの並列開発」という活用法があることを知らなければ、検索しようがありません。
本書が目指しているのは、そうした断片的な知識を1本の道筋としてつなげることです。基礎編で学んだコマンドが、チーム開発ではどう活きるのか。コンフリクト解消のスキルが、AI並列開発でなぜ重要になるのか。各章が次の章の土台になるように構成し、ハンズオンを交えて実際にご自身の手で体験していただくことで、プロの現場で通用するスキルを最短ルートで身につけられるようにしました。
動画やネット記事で学んだ知識は、本書を読むことでさらに深まるはずです。「あの動画で見た操作は、こういう意味だったのか」と腑に落ちる瞬間があれば、著者としてこれ以上嬉しいことはありません。
本書を読み終えると、以下のことができるようになります。
一人開発からチーム開発へ。本書があなたの次のステップをサポートします。
Vol. I：基礎編
| 章 | 内容 |
|---|---|
| 第1章 | AI時代になぜGitが必要なのか |
| 第2章 | Gitの基本概念を理解しよう |
| 第3章 | 開発環境を整えよう |
| 第4章 | ターミナルを使ってみよう |
| 第5章 | Gitコマンド入門 |
| 第6章 | ローカルでGitを実践しよう |
| 第7章 | AIエージェントとGitを連携させよう |
Vol. II：マスター編（本書）
| 章 | 内容 |
|---|---|
| 第1章 | Vol. II入門とGitHubのセットアップ |
| 第2章 | リモートリポジトリの基本操作 |
| 第3章 | 開発フローのルール |
| 第4章 | コンフリクト解消マスター |
| 第5章 | AIツールとGitを連携させよう |
| 第6章 | チーム開発で活躍しよう |
| 第7章 | GitHub Actionsで自動化しよう |
| 第8章 | トラブルシューティングと応用テクニック |
| 第9章 | さらなる一歩 – worktreeとGit LFS |
本書は第1章から順番に読むことをおすすめします。各章は前の章の内容を前提としているため、順番に進めることで理解が深まります。
ただし、すでにGitHubアカウントを持っていてSSH鍵も設定済みの方は、第2章から始めても構いません。その場合は、第1章の「前提知識の確認」だけ目を通しておくと安心です。
各セクションの見出しには目次へのリンクがあります。復習したいときや特定のコマンドを確認したいときは、目次から素早く該当ページにジャンプできます。
本書では、実際に手を動かして操作するセクションに Hands-On というラベルを付けています。
プログラミングやGitの学習は、読むだけでは身につきません。自分の手でコマンドを入力し、画面の変化を確認し、エラーに遭遇して解決する——この繰り返しが、知識を「使えるスキル」に変えていきます。
Hands-Onラベルが付いているセクションでは、ぜひ本書と同じ操作を試してください。最初はうまくいかないこともあるかもしれませんが、それも学習の一部です。エラーが出たら、メッセージをよく読んで原因を考える。その経験が、実際の開発現場で役立つ力になります。
本書では、多くのコマンド例が登場します。「コマンド」という言葉を聞いて、うっ…と身構えてしまう方もいるかもしれません。大丈夫です。
今すぐ覚える必要はありません。 本書では、コマンドが登場するたびに一つ一つ丁寧に説明します。「覚える」のではなく「使いながら慣れる」のが一番の近道です。
ターミナル（またはコンソール、コマンドライン）は、文字を入力してコンピュータに指示を出すツールです。OSによって標準のターミナルが異なります。
| OS | 標準ターミナル | プロンプト記号 |
|---|---|---|
| Mac | ターミナル.app（zsh） | % |
| Windows | PowerShell / コマンドプロンプト | > |
| Linux | 各種ターミナル（bash） | $ |
Windowsユーザーへの重要なお知らせ: 本書では、Windowsでも「Git Bash」を使用することを前提としています。Git BashはGitをインストールすると一緒にインストールされるbashシェルで、MacやLinuxと同じコマンドが使えます。
PowerShellやコマンドプロンプトでは、一部のコマンドが動作しなかったり、出力形式が異なったりします。本書の内容をそのまま試すには、Git Bashを使用してください。
本書では、ターミナルでの操作を以下のような黒い背景のボックスで表示します。
$ git status
On branch main
nothing to commit, working tree cleanターミナル表示で重要なのが、行頭のプロンプト記号です。お使いの環境によって表示が異なります。
| 環境 | 実際の表示例 |
|---|---|
| Git Bash / Linux | $ |
| Mac (zsh) | % |
| Windows PowerShell | PS C:\> |
| Windows コマンドプロンプト | C:\> |
本書では $ で統一しています。
お使いの環境で % や >
が表示されていても、$
の後に書かれているコマンドをそのまま入力してください。
$ git status
On branch main$ がある行:
あなたが入力するコマンド（$ 自体は入力しない）
$ がない行:
コンピュータからの出力（結果）
つまり上の例では、git status
と入力すると、On branch main という結果が返ってきます。
#）の意味コード内の #
は「コメント」の始まりを示す記号です。#
からその行の終わりまでがコメントとして扱われ、コンピュータには無視されます。つまり、入力する必要はありません。
# この行は全体がコメント（入力不要）
$ git add index.html # ←この部分だけがコメント#
があるので、行全体がコメントgit add index.html
がコマンド、# 以降の説明文はコメント上の例で実際に入力するのは git add index.html
の部分だけです。
本書では、実際の値に置き換える部分を <>
で囲んで示します。
$ git commit -m "<メッセージ>"
$ git switch <ブランチ名>
$ git clone <リポジトリURL>上の例では、<メッセージ>
の部分を実際のメッセージ（例:
"Add new feature"）に置き換えて実行します。<>
自体は入力しません。
| 表記 | 意味 |
|---|---|
$ |
ユーザーが入力するコマンド（$ は入力しない） |
# |
コメント（説明用、入力不要） |
<値> |
実際の値に置き換える部分 |
-x |
短いオプション |
--option |
長いオプション |
... |
出力の省略 |
MacやLinuxの場合
MacやLinuxでは、標準のターミナル（zshやbash）がそのまま使えます。特別な設定は必要ありません。本書のコマンドはすべてそのまま実行できます。
本書を最大限に活用するために、Gitの基本概念を確認しておきましょう。すでにご存じの方はさっと目を通して、次のセクションに進んでください。
Gitを使ううえで欠かせない4つの概念があります。
リポジトリ（Repository）
リポジトリは、プロジェクトのファイルと変更履歴を保存する場所です。プロジェクトフォルダの中にある.gitという隠しフォルダがその正体で、git initコマンドで作成されます。リポジトリがあるフォルダでは、Gitによるバージョン管理が有効になります。
コミット（Commit）
コミットは、プロジェクトの状態を記録したスナップショットです。ゲームでいう「セーブポイント」のようなもので、いつでもその時点の状態に戻れます。コミットを作成するときには、何を変更したかを説明する「コミットメッセージ」を添えます。
ブランチ（Branch）
ブランチは、作業の分岐点を示す軽量なポインタです。mainブランチが本流で、機能追加やバグ修正は別のブランチで行います。作業が完了したら、そのブランチをmainにマージ（統合）します。ブランチを使うことで、本番コードに影響を与えずに新機能を開発できます。
ステージングエリア（Staging Area）
ステージングエリアは、コミットする変更を選んで準備する場所です。git addコマンドで変更をステージングエリアに追加し、git commitでまとめてコミットします。この仕組みにより、関連する変更だけを1つのコミットにまとめられます。
本書で使う基本的なGitコマンドを確認しておきましょう。
| コマンド | 説明 | 使用例 |
|---|---|---|
git init |
リポジトリを初期化 | git init |
git status |
現在の状態を確認 | git status |
git add |
ステージングに追加 | git add ファイル名 |
git commit |
コミットを作成 | git commit -m "メッセージ" |
git log |
履歴を確認 | git log --oneline |
git branch |
ブランチを一覧 | git branch |
git switch |
ブランチを切り替え | git switch ブランチ名 |
git merge |
ブランチを統合 | git merge feature |
これらのコマンドに不安がある場合は、Vol. I の第5章「Gitコマンド入門」を復習しておくと安心です。本書では、これらの基本コマンドを前提として、リモートリポジトリとの連携やチーム開発のワークフローを学んでいきます。
GitHubは、世界最大のコード共有プラットフォームです。2008年にサービスを開始し、2026年現在では1億人以上の開発者が利用しています。GitとGitHubの違い、GitHubを使うメリットについては、第2章で詳しく説明します。
すでにGitHubアカウントをお持ちの方は、次のセクション「SSH鍵の設定」に進んでください。
GitHubアカウントは無料で作成できます。以下の手順で進めましょう。
ブラウザで https://github.com/signup を開きます。以下のような画面が表示されます。
GoogleアカウントやAppleアカウントでサインアップすることもできますが、ここではメールアドレスで登録する方法を説明します。
「Email」欄に普段使用しているメールアドレスを入力します。このアドレスに確認メールが届くので、すぐに確認できるアドレスを使いましょう。
「Password」欄にパスワードを入力します。画面に表示されているように、以下のどちらかの条件を満たす必要があります。
セキュリティのため、他のサービスと同じパスワードは避けましょう。
「Username」欄にユーザー名を入力します。使用できる文字は以下のとおりです。
このユーザー名はgithub.com/ユーザー名というURLの一部になり、あなたのGitHub上の名前として表示されます。
ユーザー名の選び方
ユーザー名は後から変更できますが、変更するとプロフィールURLも変わります。過去に共有したリンクが無効になるため、最初から慎重に選びましょう。
就職活動でGitHubを見られることも多いため、プロフェッショナルな印象を与える名前がおすすめです。本名をベースにしたもの（例:
taro-yamada）や、覚えやすいハンドルネームが良いでしょう。
「Your Country/Region」で居住国を選択します。日本在住の方は「Japan」を選びましょう。
「Email preferences」のチェックボックスは、GitHubからの製品アップデートやお知らせを受け取るかどうかの設定です。不要であればチェックを外したままで構いません。
すべての項目を入力したら、「Create account」ボタンをクリックします。
入力したメールアドレスに確認メールが届きます。メールを開き、記載されている認証コードを入力するか、認証リンクをクリックして登録を完了します。
これでGitHubアカウントの作成は完了です
GitHubの無料プラン（Free）でも、十分な機能が使えます。
個人開発や小規模なチーム開発であれば、無料プランで十分です。
SSH鍵を設定すると、GitHubとの通信を安全かつ便利に行えます。一度設定すれば、パスワードを毎回入力する必要がなくなります。
SSH（Secure Shell）は、ネットワーク経由で安全に通信するための仕組みです。SSH鍵は「秘密鍵」と「公開鍵」のペアで構成されています。
イメージとしては、秘密鍵が「自分だけが持つ鍵」、公開鍵が「玄関の錠前」のような関係です。錠前（公開鍵）は公開しても、対応する鍵（秘密鍵）がなければ開けられません。
GitHubとの通信にはHTTPSとSSHの2つの方法がありますが、本書ではSSHを推奨します。
ターミナル（Windowsの場合はGit Bash）を開いて、以下のコマンドを実行します。
# SSH鍵の生成（ed25519形式を推奨）
$ ssh-keygen -t ed25519 -C "your_email@example.com"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/username/.ssh/id_ed25519):
# → そのままEnterでOK（デフォルトの場所に保存）
Enter passphrase (empty for no passphrase):
# → パスフレーズを設定（空欄でも可、設定するとより安全）
Enter same passphrase again:
# → 同じパスフレーズを再入力
Your identification has been saved in /Users/username/.ssh/id_ed25519
Your public key has been saved in /Users/username/.ssh/id_ed25519.pubコマンド中の your_email@example.com
は、GitHubに登録したメールアドレスに置き換えてください。
パスフレーズは設定しなくても動作しますが、設定しておくとセキュリティが向上します。パスフレーズを設定した場合、初回のSSH接続時に入力を求められます。
デフォルトではid_ed25519という名前で保存されますが、以下のような場合は別の名前をつけることをおすすめします。
名前をつける場合は、-fオプションでファイルパスを指定します。
# -f オプションで保存先を指定
$ ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519_github_personal名前の例： - id_ed25519_github_personal（GitHub個人用）
- id_ed25519_github_work（GitHub仕事用） -
id_ed25519_gitlab（GitLab用）
名前をつけた場合は、~/.ssh/configファイルでどの鍵をどのサービスに使うか設定する必要があります。詳しくは第7章の応用テクニックで説明します。初めての方は、まずデフォルトの名前で進めることをおすすめします。
生成した公開鍵の内容を表示し、コピーします。
# 公開鍵の内容を表示
$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
# 表示された内容を手動でコピーしてもいいですが、
# 以下のコマンドで直接クリップボードに取り込むこともできます。
# Mac
$ pbcopy < ~/.ssh/id_ed25519.pub
# Linux（xclipがインストールされている場合）
$ xclip -selection clipboard < ~/.ssh/id_ed25519.pub
# Windows（Git Bash）
$ clip < ~/.ssh/id_ed25519.pub鍵ファイルに名前をつけた場合は、そのファイル名を指定します。
# 名前をつけた場合の例
$ cat ~/.ssh/id_ed25519_github_personal.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your_email@example.com
# 表示された内容を手動でコピーしてもいいですが、
# 以下のコマンドで直接クリップボードに取り込むこともできます。
# Mac
$ pbcopy < ~/.ssh/id_ed25519_github_personal.pub
# Linux
$ xclip -selection clipboard < ~/.ssh/id_ed25519_github_personal.pub
# Windows（Git Bash）
$ clip < ~/.ssh/id_ed25519_github_personal.pubssh-ed25519
から始まり、メールアドレスで終わる1行全体をコピーしてください。途中で改行が入らないよう注意しましょう。
コピーした公開鍵をGitHubに登録します。
GitHubにログインし、右上のプロフィールアイコンをクリックします。表示されるメニューからSettingsを選択します。
左側のメニューからSSH and GPG keysをクリックします。SSH鍵の管理画面が表示されます。
緑色のNew SSH keyボタンをクリックします。
以下の情報を入力します。
ssh-ed25519で始まる1行）緑色のAdd SSH keyボタンをクリックして完了です。GitHubのパスワード確認を求められる場合があります。
設定が正しく完了したか確認しましょう。
$ ssh -T git@github.com
The authenticity of host 'github.com (20.27.177.113)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (ED25519) to the list of known hosts.
Hi username! You've successfully authenticated, but GitHub does not provide shell access.初回接続時は、GitHubのフィンガープリント確認が表示されます。yesと入力してください。
「Hi username! You’ve successfully authenticated」というメッセージが表示されれば、SSH接続は成功です。「GitHub does not provide shell access」という部分は正常なメッセージなので、心配ありません。
秘密鍵は絶対に公開しない
~/.ssh/id_ed25519（拡張子なし）は秘密鍵です。このファイルを他人に見せたり、GitHubにアップロードしたり、メールで送ったりしないでください。
公開するのは.pubがついた公開鍵（id_ed25519.pub）のみです。
万が一、秘密鍵が漏洩した可能性がある場合は、すぐに新しい鍵ペアを生成し、GitHubから古い公開鍵を削除してください。
SSH接続でエラーが出た場合の対処法です。
「Permission denied (publickey)」と表示される
公開鍵がGitHubに登録されていないか、秘密鍵が正しく読み込まれていない可能性があります。
# SSH鍵が読み込まれているか確認
$ ssh-add -l
# 鍵が表示されない場合は追加
$ ssh-add ~/.ssh/id_ed25519ポート22がブロックされている
企業や学校のネットワークでは、ポート22がブロックされていることがあります。その場合は、ポート443経由でSSH接続する設定を追加します。
# ~/.ssh/config ファイルを作成または編集
$ code ~/.ssh/config以下の内容を追加してください。
Host github.com
Hostname ssh.github.com
Port 443
User gitGitHubには多くの機能がありますが、最初に覚えるべきものはごく一部です。本書を読み進める中で、必要な機能を順番に学んでいきましょう。
GitHubにログインすると、ダッシュボード（ホーム画面）が表示されます。ここでは以下の情報を確認できます。
リポジトリページには、複数のタブがあります。それぞれの役割を見ていきましょう。
Code タブ
デフォルトで表示されるタブです。リポジトリのファイルやフォルダを一覧できます。
README.mdが自動的に表示されるIssues タブ
バグ報告や機能リクエストを管理する場所です。
Pull Requests タブ
コード変更の提案とレビューを行う場所です。
Pull Request の詳しい使い方は、第5章「チーム開発で活躍しよう」で学びます。
Actions タブ
CI/CD（継続的インテグレーション/継続的デリバリー）のワークフローを管理します。
GitHub Actions の詳しい使い方は、第7章「GitHub Actionsで自動化しよう」で学びます。
Settings タブ
リポジトリの設定を行います（自分がオーナーまたは管理者のリポジトリのみ表示）。
リポジトリページ右上にあるボタンの役割を確認しましょう。
最初から全部覚える必要はありません
GitHubの機能は多岐にわたりますが、最初からすべてを覚える必要はありません。本書では、必要な機能を使う場面で順番に解説していきます。
まずは「リポジトリページでコードを見る」「<> Code ボタンでクローン URL を取得する」の2つだけ覚えておけば十分です。
リポジトリをローカルにクローン（コピー）するとき、2種類のURLが選べます。
git@github.com:username/repo.githttps://github.com/username/repo.gitSSH vs HTTPS: どちらを使うべき？
SSHは一度鍵を設定すれば認証が不要で、より安全です。HTTPSは設定不要ですが、pushのたびにPersonal Access Token（PAT）の入力が必要です。前のセクションでSSH鍵を設定した方は、SSH URLを使いましょう。
この章では、Vol. IIで学ぶ内容の全体像と、GitHubを使うための準備を完了しました。
SSH接続テストで「Hi username! You’ve successfully authenticated」と表示された場合、何を意味しますか？
Gitの「ブランチ」について正しいものはどれですか？
次章予告: 第2章では、いよいよGitHubにリポジトリを作成し、ローカルリポジトリと接続します。push、pull、cloneといったリモート操作の基本を学びましょう。