Git / GitHubの始め方 - Hiro実践ガイド

OVERVIEW

Gitは「履歴」、GitHubは「共有とレビューの場所」

GitとGitHubは別物です。Gitはあなたのパソコンの中で変更履歴を記録するバージョン管理ソフト。 GitHubはそのGitの履歴をインターネット上に置いて、他の人やAI、別の端末と共有・レビューするサービスです。まずはこの2つの役割の違いを掴むのが、迷子にならない第一歩です。

記

記録する（Git）

ファイルの変更を「コミット」という保存点で残します。いつ・誰が・何を変えたかが履歴に積み上がり、過去の状態へ戻せます。

共

共有する（GitHub）

手元の履歴をリモートに「プッシュ」して共有します。他の端末から「クローン」したり、チームで同じ履歴を扱えます。

守

守られる（安全帯）

AIや自分が壊しても、コミットしてあれば元に戻せます。Gitは「失敗してもやり直せる」ための保険です。

WHY NOW

AIがファイルを編集する時代こそ、Gitが効いてくる

Claude CodeやCodexのようなAIエージェントは、実際にファイルを書き換え、コマンドを実行します。便利な反面、「気づいたら意図しない変更が混ざっていた」も起こります。Gitがあれば、変更の前後を見比べ、嫌な変更だけ捨て、良い変更だけ残せます。

1

何が変わったか見える

git diffで、AIが触った差分を1行単位で確認できます。レビューしないまま進めるのが一番危険です。

2

嫌な変更を捨てられる

納得できない編集はgit restoreで元に戻せます。コミット前なら、なかったことにできます。

3

良い状態に戻れる

うまくいった時点でコミットしておけば、その後どれだけ壊れても、その保存点まで戻せます。

4

作業を分けられる

ブランチを切れば、本線を壊さずにAIへ実験させられます。ダメなら丸ごと捨てられます。

5

誰が何をしたか残る

自分の手作業、AIの編集、他の人の変更が履歴に残るので、原因の切り分けがしやすくなります。

P

公開前に確認できる

GitHubに上げる前に差分を見れば、秘密情報や事故になる変更を公開前に止められます。

覚えておくのは1つだけ。AIに編集させる前にgit status、編集させた後にgit diff。この2つを習慣にすると、AI活用の怖さが一気に減ります。

CONCEPTS

先に押さえる用語は6つだけ

Gitは用語が多くて身構えがちですが、最初に必要なのは6つです。残りは使いながら覚えれば十分です。

用語	意味	イメージ
リポジトリ（repo）	Gitで管理するプロジェクトの入れ物	履歴つきの作業フォルダ
コミット（commit）	変更をまとめた保存点	ゲームのセーブポイント
ステージ（add）	次のコミットに含める変更を選ぶ場所	レジに乗せるカゴ
ブランチ（branch）	本線から分けた作業ライン	並行世界の作業場所
リモート（remote）	GitHubなど、ネット上の置き場所	共有のクラウド倉庫
プル / プッシュ	リモートから取り込む / 上げる	同期のダウンロード / アップロード

手元で編集

作業ツリー

ファイルを書き換えている状態。まだGitには記録されていません。

→

add

ステージ

次のコミットに含める変更を選びます。git addでカゴに入れます。

→

commit

履歴

git commitで保存点を作ります。ここまで来て初めて「戻せる」状態です。

SETUP

最初のセットアップは「インストール、名前設定、GitHub登録」

Gitのインストールと、コミットに残る名前・メールの設定、GitHubアカウントの用意。この3つを最初に済ませると、後がスムーズです。

1

Gitをインストールする

macOSはHomebrew、WindowsはGit for Windows（Git Bash付き）が定番です。入っているか先に確認します。

macOS

Homebrew

git --version
brew install git

Windows

Git for Windows

# https://git-scm.com/download/win
# からインストーラを入手して実行
git --version

Windowsはインストール時に「Git Bash」が入ります。以降のコマンドはGit BashかWSLで実行すると迷いにくいです。

2

名前とメールを設定する

コミットには「誰が変更したか」が記録されます。最初に一度だけ設定します。GitHubで使うメールに合わせるのがおすすめです。

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

既定のブランチ名をmainに揃えておくと、GitHubと一致して迷いません。
git config --global init.defaultBranch main

3

GitHubアカウントを作る

共有・レビュー・バックアップにGitHubを使います。アカウントを作り、無料の範囲で十分始められます。

# https://github.com で登録
# ユーザー名・メール・パスワードを設定

4

GitHubに繋ぐ認証を用意する

HTTPS接続なら、コマンド操作をまとめてくれるGitHub CLI（gh）が一番ラクです。gh auth loginでブラウザ認証できます。

GitHub CLI

SSH鍵

慣れてから

ssh-keygen -t ed25519 -C "you@example.com"
# 公開鍵をGitHubのSettings > SSH keysに登録

パスワード認証は使えません。HTTPSなら個人アクセストークン（PAT）かGitHub CLI、より安全にしたいならSSH鍵を使います。

FIRST REPO

最初の1回 ─ リポジトリを作って初コミット

始め方は2通り。手元のフォルダをGit管理にするgit initか、GitHubにある既存リポジトリを取ってくるgit cloneです。

A. 手元のフォルダから始める

新しく作るプロジェクトはこちら。フォルダをGit管理にして、最初のコミットを作ります。

B. GitHubから取ってくる

既にあるリポジトリを触るならこちら。git cloneで履歴ごと手元にコピーします。

A. 新規プロジェクトを管理下に置く

git init

cd ~/work/my-project
git init                 # このフォルダをGit管理にする
git add .                # 全ファイルをステージに乗せる
git commit -m "first commit"   # 最初の保存点を作る

B. 既存リポジトリを取ってくる

git clone

git clone https://github.com/your-name/your-repo.git
cd your-repo
git status               # まず状態を見るクセをつける

GitHubに新規リポジトリを作って繋ぐ

gh CLI

# 手元で git init 済みのフォルダから
gh repo create my-project --private --source=. --remote=origin
git push -u origin main

-u origin mainの-uは「このブランチの上げ先をoriginのmainに覚えさせる」指定です。2回目以降はgit pushだけで上げられます。

DAILY

毎日使う基本コマンドは6つ

最初に覚えるのはこれだけでOKです。statusで見て、addして、commitで保存。diffとlogで確認します。

`git status`

今どのファイルが変わっているか、何がステージ済みかを表示します。迷ったらまずこれ。

`git add <file>`

次のコミットに含める変更を選びます。全部ならgit add .。

`git commit -m "..."`

ステージした変更を保存点にします。メッセージは後で読んで分かる言葉に。

`git diff`

まだステージしていない変更を1行単位で表示します。レビューの主役です。

`git log --oneline`

コミット履歴を1行ずつ一覧します。どこまで進んだか俯瞰できます。

`git pull`

リモートの最新を取り込みます。作業開始前に引いておくと衝突が減ります。

$ git status
$ git add README.md
$ git commit -m "Update README"
$ git log --oneline
$ git push

コミットメッセージは「何をしたか」が一目で分かる短文に。fix typo、Add login formのように、動詞から始めると後で読みやすくなります。

BRANCH

ブランチは「本線を壊さない作業場所」

いきなりmainを書き換えるのではなく、作業ごとにブランチを切ります。失敗しても本線は無傷。 AIに実験させるときも、ブランチを分けておけば丸ごと捨てられます。

1

ブランチを作って移る

switch -cで新しいブランチを作り、同時にそこへ移ります。名前は内容が分かるものに。

git switch -c feature/login-form

2

そのブランチで作業してコミット

編集・add・commitはいつも通り。変更はこのブランチにだけ積まれます。

git add .
git commit -m "Add login form"

3

本線に戻して取り込む

完成したらmainへ戻り、ブランチの成果をマージします。チーム作業ではこの取り込みをGitHubのPRで行うのが安全です。

git switch main
git merge feature/login-form

4

使い終わったブランチは消す

取り込み済みのブランチは削除して整理します。履歴はmainに残るので消して大丈夫です。

git branch -d feature/login-form

ブランチ名はfeature/○○（機能追加）、fix/○○（修正）のように接頭辞をつけると、後で見たとき何の作業か分かります。

GITHUB

GitHubで共有・レビューする ─ push と Pull Request

手元のコミットをGitHubにpushして共有します。チームや他人のレビューを通したい変更は、直接mainに入れず「プルリクエスト（PR）」で提案します。

PUSH

上げる

ブランチをGitHubにpushして、変更を共有できる状態にします。

→

PR

提案する

「このブランチをmainに入れたい」とPRで提案。差分とコメントで議論します。

→

MERGE

取り込む

レビューが通ったらmainにマージ。これでみんなの本線に反映されます。

ブランチを上げてPRを作る

gh CLI

git push -u origin feature/login-form
gh pr create --title "Add login form" --body "ログイン画面を追加"

PRの状態を見る・マージする

レビュー後

gh pr status            # 自分のPRの状況を確認
gh pr view --web        # ブラウザでPRを開く
gh pr merge --squash    # レビューが通ったらマージ

なぜ直接mainに入れないか

PRを挟むと、マージ前に差分を見られ、コメントで指摘でき、CIの自動テストも走ります。事故を公開前に止める仕組みです。

ブラウザだけでもOK

ghを使わず、GitHubの画面からPR作成・レビュー・マージもできます。最初はブラウザ操作から入っても問題ありません。

WITH AI

AIエージェントと一緒に使うときのGit運用

Claude CodeやCodexにファイルを編集させるなら、Gitは「お願い」ではなく「前提」です。編集の前後を必ずGitで挟むだけで、AIの作業をレビュー可能な状態に保てます。

BEFORE

編集前

git statusで、未整理の変更がないか確認。きれいな状態からAIに渡します。

→

DURING

編集中

大きめの変更はブランチを切って実験。ダメなら丸ごと捨てられる状態にします。

→

AFTER

編集後

git diffでAIの差分をレビュー。納得したものだけcommitします。

AIにGit差分を説明してもらう

レビュー前

今のgit差分を初心者向けに説明して。
変更ファイルごとに、何が変わったか、なぜ必要か、確認すべきリスクをまとめて。
まだコミットはしないで。

AIにコミットメッセージを任せる

保存点づくり

ステージ済みの変更に合うコミットメッセージを1行で提案して。
日本語で、何をしたかが一目で分かる動詞始まりにして。

git pushのような外部へ影響する操作は、AIに任せきりにせず人間が最終実行するのが安全です。公開・送信・本番反映は、差分を自分の目で見てから行います。

AIが秘密情報に触れないよう、.envや鍵ファイルは.gitignoreに入れ、コミットに混ざらないようにします。詳しくは下の「戻す・守る」を参照。

TROUBLESHOOT

よくある詰まりは、メッセージで切り分ける

Gitの初期トラブルは、ほとんどが「認証」「コンフリクト」「push拒否」「コミットし忘れ」のどれかです。慌てず、まずメッセージを読んで、どの種類かを分けます。

状況 / メッセージ	原因	最初の対処
`Authentication failed`	パスワード認証は不可。トークンか`gh`未設定	`gh auth login`、またはPAT / SSH鍵を設定
`Updates were rejected`（push拒否）	リモートに自分の手元にない更新がある	`git pull`で取り込んでからpush
`CONFLICT`（マージ衝突）	同じ箇所を別々に変更した	該当ファイルの`<<<<`～`>>>>`を手で直し、add → commit
`detached HEAD`	ブランチではなく特定コミットを見ている	`git switch main`でブランチへ戻る
`nothing to commit`	変更が無い、または`add`し忘れ	`git status`で状態を確認、必要なら`git add`
間違えてコミットした	直前のコミットを取り消したい	`git reset --soft HEAD~1`で変更を残して取り消し

コンフリクトを解消する流れ

マージ衝突

git status                 # どのファイルが衝突したか確認
# エディタで <<<<<<< ======= >>>>>>> を手で直す
git add <直したファイル>
git commit                 # 衝突解消を確定

詰まったら、AIに「このGitのエラーの意味と、安全な直し方を初心者向けに教えて。まだ実行はしないで」と聞くのも有効です。意味を理解してから手を動かします。

UNDO / SAFETY

戻す・守る ─ 失敗からの復旧と秘密情報の扱い

Gitの本当の価値は「戻せること」です。状況に応じた戻し方を知っておくと、AIに大胆に任せても怖くありません。あわせて、秘密情報をコミットに混ぜない設定もここで押さえます。

`git restore <file>`

コミット前の編集を捨てて、直前のコミット状態に戻します。AIの嫌な変更を消すときの基本。

`git restore --staged <file>`

addでステージしたのを取り消します。変更自体は残ります。

`git reset --soft HEAD~1`

直前のコミットだけ取り消し、変更内容は手元に残します。コミットし直したいとき。

`git revert <commit>`

過去のコミットを「打ち消すコミット」で取り消します。共有後の安全な戻し方です。

`git stash`

作業中の変更を一時退避します。急に別のことをやる必要が出たときに便利。

`git checkout <commit> -- <file>`

特定のファイルだけ、過去の状態に戻します。1ファイルだけやり直したいとき。

共有済み（push済み）の履歴をresetで書き換えると、他の人やAIの手元と食い違います。共有後の取り消しはgit revertを使うのが安全です。

.gitignoreで秘密情報を守る

コミットに混ぜない

# Environment / secrets
.env
.env.*
secrets/
*.pem
*.key

# OS / editor
.DS_Store
node_modules/

もし秘密情報をうっかりコミット・push してしまったら、.gitignoreに足すだけでは履歴に残ります。その鍵やトークンは「漏れた」前提で速やかに無効化（rotate）し、新しいものに差し替えるのが最優先です。

CHEAT SHEET

コマンド早見表

迷ったらここ。よく使う順に並べています。まずは上半分を覚えれば十分回せます。

やりたいこと	コマンド
今の状態を見る	`git status`
変更の中身を見る	`git diff`
変更を保存対象に乗せる	`git add .`
保存点を作る	`git commit -m "メッセージ"`
履歴を見る	`git log --oneline`
リモートの最新を取り込む	`git pull`
リモートに上げる	`git push`
ブランチを作って移る	`git switch -c ブランチ名`
ブランチを移る	`git switch ブランチ名`
取り込む（マージ）	`git merge ブランチ名`
編集を捨てて戻す	`git restore ファイル名`
直前のコミットを取り消す	`git reset --soft HEAD~1`
共有後に安全に取り消す	`git revert コミットID`
作業を一時退避する	`git stash`
リポジトリを取ってくる	`git clone URL`
PRを作る	`gh pr create`

FIRST WEEK

最初の1週間ロードマップ

1日で全部覚えようとしないこと。小さく触って、コミットで戻せる状態を作り、GitHub連携へ広げていきます。

1日目: 設定する

インストール、名前・メール設定、GitHub登録。git --versionで確認まで。

2日目: 初コミット

練習用フォルダでgit init → add → commit。git logで履歴を見る。

3日目: status と diff

ファイルを編集してgit statusとgit diffを読む。変更が見える感覚を掴む。

4日目: GitHubに上げる

gh repo createでリモートを作り、git push。ブラウザで確認する。

5日目: ブランチとPR

ブランチを切って変更し、PRを作ってマージする一連を一度やってみる。

6-7日目: AIと組む

AIに小さな編集を頼み、git diffでレビューしてコミット。戻し方も1回試す。

RULES

失敗しにくいGit運用ルール

コマンドを全部覚える必要はありません。この習慣だけ守れば、AIと組んでも事故が起きにくくなります。

✓

作業前に git status を見る未整理の変更が残っていないか確認します。きれいな状態から始めると、後で差分が読みやすくなります。

✓

編集後は git diff でレビューする自分やAIが何を変えたかを必ず確認してからコミットします。読まずに進めないこと。

✓

こまめに小さくコミットする1つの目的につき1コミット。戻したいときに、戻す範囲を小さくできます。

✓

大きい変更はブランチを切る本線を壊さず実験できます。ダメなら丸ごと捨てられます。AIの実験にも有効です。

✓

秘密情報をコミットしない.env、鍵、トークン、顧客情報は.gitignoreで除外。混ざったら鍵を無効化して差し替えます。

✓

push の前にもう一度差分を見る公開・共有は影響が大きい操作です。上げる前に自分の目で最終確認します。

✓

共有後の取り消しは revert を使うpush済みの履歴をresetで書き換えると食い違います。打ち消しはgit revertで安全に。

SOURCES

参照した公式情報

コマンドのオプションや認証方法、対象プランは更新される可能性があります。公開・配布前に公式ページで最終確認してください。