Gitをこれから学ぶ方、普段は何となく操作している方、チーム開発でトラブルに直面した方に向けた保存版です。Windows・macOS・Linuxのターミナルで使うコマンドを中心に説明します。特記がなければ既定ブランチ名は
mainとします。
はじめに
Gitは「コマンドを丸暗記するもの」ではありません。作業場所・記録の準備場所・履歴・共有先という4つの場所を理解すると、操作の意味がつながります。
この記事で扱うのは、Gitのインストールから、GitHub/GitLabでのチーム開発、コンフリクト解決、取り消し・復旧、実務の運用ルールまでです。最初からすべて覚える必要はありません。困った場面で戻ってこられる辞書として使ってください。
この記事の読み方
| 対象 | おすすめの章 |
|---|---|
| はじめて使う | 第1～5章 |
| 日常の開発で使う | 第6～9章 |
| エラーが出て困っている | 第10～12章 |
| 複数人開発を改善したい | 第13～15章 |
目次
- GitとGitHub/GitLabの違い
- Gitの4つの場所を理解する
- インストールと初期設定
- リポジトリを作成・取得する
- 日常の基本操作（add / commit / push / pull）
- ブランチを使いこなす
- merge・rebase・fast-forwardの違い
- Pull Request / Merge Requestによるチーム開発
- コンフリクトを安全に解決する
- 取り消し・復旧（restore / reset / revert / reflog）
- よくあるエラーと対処法
- stash・cherry-pick・tagなどの便利機能
- .gitignore・認証・セキュリティ
- 現場で使える運用ルール
- コマンド早見表・練習課題
第1章 GitとGitHub/GitLabの違い
Gitはファイルの変更履歴を管理する分散型バージョン管理システムです。GitHub / GitLabはGitのリポジトリをホスティングし、レビューやIssue管理、CI/CDなどの開発支援機能を提供するサービスです。
| 用語 | 役割 |
|---|---|
| Git | 履歴の保存、ブランチ作成、統合 |
| GitHub | Gitリポジトリの共有、Pull Request（PR）、Actionsなど |
| GitLab | Gitリポジトリの共有、Merge Request（MR）、CI/CDなど |
| リポジトリ | プロジェクトの履歴を保持する場所 |
| コミット | ファイルの状態と変更理由を履歴に記録する単位 |
| ブランチ | あるコミットを指す、移動可能な名前 |
Gitはインターネットがなくても、ローカルにコミットできます。ただしGitHub/GitLabへpushするには通信と適切な権限が必要です。
第2章 Gitの4つの場所を理解する
※ pull はリモートの変更を取得し、現在のブランチにmergeまたはrebaseで統合します。図は概念図です。
最重要ポイント：addとcommitとpushは別の操作です。
-
git add：次のコミットに含める変更を選ぶ -
git commit：ローカルに履歴を記録する -
git push：その履歴をリモートへ送信する
また、HEADは通常「現在チェックアウトしているブランチ（またはコミット）」を示す参照です。originはリモートの名前であり、GitHub固有の予約語ではありません。
第3章 インストールと初期設定
Git公式サイトからインストールします。WindowsではGit for Windows、macOSでは公式配布版やHomebrew、Linuxではディストリビューションのパッケージ管理ツールを利用できます。
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global --list
ユーザー名とメールアドレスはコミットの著者情報です。GitHubでメールアドレスを公開したくない場合は、GitHubが案内するnoreplyアドレスも検討してください。
プロジェクト固有の設定にしたい場合は、リポジトリ内で--globalを外して実行します。
git config user.email "work@example.com"
git config --show-origin --get user.email
第4章 リポジトリを作成・取得する
4-1. 新しいフォルダで始める
mkdir git-practice
cd git-practice
git init
git status
git initで.gitディレクトリが作られます。ここに履歴や設定が保存されます。
4-2. 既存のGitHubリポジトリを取得する
git clone https://github.com/OWNER/REPOSITORY.git
cd REPOSITORY
git remote -v
cloneした場合、通常はoriginが設定済みです。改めてgit remote add originを実行する必要はありません。
4-3. 既存のローカルプロジェクトをGitHubへ登録する
GitHub側に空のリポジトリを作っておくとシンプルです。
cd existing-project
git init
git branch -M main
git add .
git commit -m "chore: initial commit"
git remote add origin https://github.com/OWNER/REPOSITORY.git
git push -u origin main
git branch -M mainは現在ブランチをmainへ改名する操作です。git push -uは追跡先（upstream）を設定します。
注意：
git add .を実行する前に.gitignoreを作り、秘密鍵、.env、ビルド成果物などが含まれていないことをgit statusで確認しましょう。GitHub上にREADMEなどの初期コミットがある場合、この手順のままでは履歴が食い違う場合があります。安易にforce pushせず、既存履歴を確認してください。
第5章 日常の基本操作
# 変更状況を確認
git status
# 未ステージの差分
git diff
# 必要なファイルだけ追加
git add src/app.js
# ステージ済みの差分を確認
git diff --staged
# コミット
git commit -m "fix: ログイン時の入力検証を修正"
# 履歴を一覧表示
git log --oneline --graph --decorate -10
# リモートへ送信
git push
git add .とgit add -p
git add .は現在位置以下の変更をまとめてステージします。意図しないファイルを含めないため、実務ではgit add ファイル名やgit add -p（差分の一部だけ選択）も便利です。
fetchとpullの違い
git fetch origin # リモート追跡参照を更新（作業ブランチは統合しない）
git log --oneline HEAD..origin/main
git pull --ff-only # fast-forwardできる場合だけ取得・統合
git pullは取得と統合をまとめて行います。想定外のマージコミットを避けたい場合は--ff-onlyを使う選択肢があります（分岐している場合は失敗します）。
第6章 ブランチを使いこなす
ブランチは機能追加や修正を分離するために利用します。
# ブランチ一覧（ローカル・リモート追跡）
git branch -a
# mainへ移動して最新を確認
git switch main
git pull --ff-only origin main
# 新しい作業ブランチを作って移動
git switch -c feature/login
# リモートへ初回push
git push -u origin feature/login
# 作業後にmainへ戻る
git switch main
git switch -cは従来のgit checkout -bに相当する、ブランチ作成・切り替えのコマンドです。
ブランチ名はfeature/login、fix/payment-error、docs/readmeなど、目的が伝わる名前にすると便利です。
第7章 merge・rebase・fast-forwardの違い
merge：履歴を統合する
git switch main
git merge feature/login
分岐している場合、通常はマージコミットが作られます。ブランチが分岐していなければfast-forwardとなる場合があります。
rebase：変更を別の土台に積み直す
git switch feature/login
git fetch origin
git rebase origin/main
rebaseはコミットを作り直すため、共有済みのブランチで安易に行うと共同作業者に影響します。基本は「自分だけが使う作業ブランチ」に限定するのが安全です。
| 観点 | merge | rebase |
|---|---|---|
| 履歴 | 分岐を残しやすい | 直線的に整理しやすい |
| 元コミットのID | 通常維持 | 書き換わる |
| 共有ブランチ | 比較的扱いやすい | 注意が必要 |
| 適した用途 | チームの変更を統合 | 未共有の作業履歴を整理 |
GitHubの「Squash and merge」は複数コミットを1つにまとめて取り込む方法です。履歴をどの粒度で残したいか、チームで方針を合わせましょう。
第8章 Pull Request / Merge Requestによるチーム開発
GitHubはPull Request（PR）、GitLabは**Merge Request（MR）**という名称を使います。
PR/MR本文には次の情報を書くとレビューが進みます。
## 変更概要
- ログインフォームの入力検証を追加
## 背景
- 空文字入力時にエラーが表示されていなかった
## 確認方法
- [ ] 正常ログインできる
- [ ] 空文字でエラー表示される
- [ ] 既存テストが通る
## 影響範囲
- 認証画面・入力バリデーション
レビュー前にはテスト、Lint、差分確認を行います。mainへの直接pushを制限するブランチ保護ルールも有効です。
第9章 コンフリクトを安全に解決する
同じ箇所を異なる形で変更すると、Gitが自動統合できずコンフリクトすることがあります。
<<<<<<< HEAD
const title = "ログイン";
=======
const title = "サインイン";
>>>>>>> feature/login
上の記号は競合箇所の境界です。どちらの変更を残すか、または組み合わせるかを判断し、記号を削除して正しいコードに整えます。
# 状態を確認
git status
# エディタで競合箇所を修正する
# テストで挙動を確認する
git add src/app.js
# merge中なら
git merge --continue
# rebase中なら
git rebase --continue
中止したい場合は、実行中の操作に応じてgit merge --abortまたはgit rebase --abortを使います。
重要：VS Codeの「Current / Incoming」などの表示や、
ours / theirsの意味は操作状況によって混乱しやすく、特にrebase時には直感と異なる場合があります。名前だけで選ばず、実際の差分を確認してください。
第10章 取り消し・復旧
まずgit statusを確認し、未コミットなのか、ローカルにコミット済みなのか、すでにpush済みなのかを切り分けます。
| やりたいこと | コマンド | 注意 |
|---|---|---|
| addを取り消す | git restore --staged file.txt |
ファイルの編集内容は保持 |
| 未ステージの編集を破棄 | git restore file.txt |
対象の編集内容が失われる |
| 直前のコミットメッセージを修正 | git commit --amend |
コミットIDが変わる |
| ローカルの直前コミットを取り消し、変更を残す | git reset --soft HEAD~1 |
履歴を書き換える |
| 公開済みの変更を打ち消す | git revert <commit> |
打ち消す新規コミットを作成 |
| 操作前の参照位置を探す | git reflog |
ローカルに記録が残る場合に有効 |
reset --hardを実行する前に
git status
git diff
git log --oneline -5
git reset --hard <commit>はブランチの位置、インデックス、作業ツリーを変更し、未コミットの変更を失わせる可能性があります。git clean -fdは未追跡ファイルも削除します。初心者向けの一括復旧コマンドとしては推奨しません。
公開済みコミットを取り消す
git revert <commit-id>
git push
共同作業中は通常、force pushよりrevertが安全です。マージコミットのrevertには親指定（-m）など追加判断が必要です。
reflogによる復旧
git reflog
# 戻したいコミットIDを確認したら、まず救出用のブランチを作る
git branch rescue <commit-id>
git switch rescue
reflogは万能なバックアップではありません。期限切れ・GC後のオブジェクトや、そもそもコミットしていない変更は救出できない場合があります。
第11章 よくあるエラーと対処法
error: remote origin already exists.
originが登録済みです。
git remote -v
# URLを変更したい場合のみ
git remote set-url origin https://github.com/OWNER/REPOSITORY.git
non-fast-forwardでpushできない
リモート側にローカルが持っていない履歴がある可能性があります。
git status
git fetch origin
git log --oneline --graph --decorate --all -15
変更の関係を確認してから、チームの方針に合わせてmerge/rebaseします。解決目的で無条件にgit push --forceしないでください。
fatal: not a git repository
現在のフォルダがGitリポジトリの外側にある可能性があります。pwd（PowerShellでも使用可能）で場所を確認し、正しいプロジェクトフォルダに移動します。
nothing to commit, working tree clean
未記録の差分がない状態です。すでにcommit済みか、.gitignoreにより対象外になっていないか確認します。
Permission denied (publickey)
SSH鍵が登録されていない、使用する鍵が違う、アクセス権がないなどの可能性があります。GitHub/GitLabのSSH設定を確認します。
HTTPSでパスワード認証ができない
GitHubではGit操作にアカウントパスワードをそのまま使う方式はサポートされません。Git Credential Manager、GitHub CLI、適切なPersonal Access Tokenなどを利用します。トークンはファイルやコマンド履歴に不用意に残さないでください。
Your local changes would be overwritten
現在の変更が切り替え先のファイルで上書きされる恐れがあります。git statusとgit diffを確認し、コミット・stash・意図的な破棄のいずれかを選びます。
第12章 stash・cherry-pick・tagなどの便利機能
stash：一時的に変更を退避する
git stash push -m "ログイン画面の作業途中"
git stash list
git stash pop
stash popは適用に成功するとstashを削除します。慎重に確認したい場合はgit stash applyで適用してからgit stash dropを使います。未追跡ファイルも含めるならgit stash push -uです（ignore対象は通常含まれません）。
cherry-pick：別ブランチのコミットを取り込む
git switch release
git cherry-pick <commit-id>
緊急修正をリリースブランチへ移す場合などに有効です。同じコミットを移動するのではなく、変更を適用した新しいコミットが通常作られます。
tag：リリース時点に名前をつける
git tag -a v1.0.0 -m "Version 1.0.0"
git push origin v1.0.0
bisect：不具合を持ち込んだコミットを探す
git bisect start
git bisect bad
git bisect good <正常だったcommit-id>
# 検証のたびにgit bisect good / badを実行
git bisect reset
worktree：ブランチを別ディレクトリで並行利用する
git worktree add ../project-hotfix -b fix/hotfix main
git worktree list
複数案件や緊急対応の切り替えに便利です。同じブランチを複数worktreeで同時にチェックアウトすることには制限があります。
第13章 .gitignore・認証・セキュリティ
.gitignoreの例です。プロジェクトの構成に応じて調整してください。
# secrets
.env
.env.*
!.env.example
*.pem
# JavaScript / TypeScript
node_modules/
dist/
# Python
.venv/
__pycache__/
*.pyc
# OS / editor
.DS_Store
.vscode/
注意：.gitignoreはすでに追跡されているファイルには効きません。追跡だけを外す場合はgit rm --cached <file>を使います。また、秘密情報をコミット・pushしてしまった場合、ファイルを消したりignoreしたりするだけでは過去の履歴から消えません。まず認証情報を失効・ローテーションし、必要に応じて管理者と履歴の除去を検討してください。
権限管理では、Privateリポジトリ、最小権限のトークン、ブランチ保護、コードレビュー、CI、秘密情報検知を組み合わせます。
第14章 現場で使える運用ルール
-
作業開始：
git status→git switch main→git pull --ff-only→ 作業ブランチ作成。 -
作業中：小さく意味のある単位でコミット。テストと
git diff --stagedを確認。 - 共有前：機密情報・不要ファイルの混入、意図しない差分、変更影響を再確認。
- レビュー時：変更理由と検証方法をPR/MRへ記載。CIの失敗を放置しない。
- マージ後：mainの更新を取得し、作業ブランチを整理。
-
事故発生時：まず
git statusとgit logを保存。reset --hard、clean、force pushを反射的に実行しない。
コミットメッセージの例
feat: CSV取り込み機能を追加
fix: 日付比較時の境界条件を修正
refactor: バリデーション処理を共通化
docs: READMEに起動手順を追加
test: 退会処理の単体テストを追加
chore: 開発用ツール設定を更新
これはConventional Commitsに近い形式です。厳密な書式よりも、チーム内で一貫したルールにすることが重要です。
第15章 コマンド早見表・練習課題
| 目的 | コマンド |
|---|---|
| 状態確認 | git status |
| 差分確認 |
git diff / git diff --staged
|
| 履歴確認 | git log --oneline --graph --all |
| リポジトリ作成 | git init |
| リポジトリ取得 | git clone <url> |
| ステージ | git add <file> |
| コミット | git commit -m "..." |
| リモート情報 | git remote -v |
| 取得のみ | git fetch origin |
| 取得して統合 | git pull --ff-only |
| リモートへ送信 | git push |
| ブランチ作成 | git switch -c <name> |
| ブランチ移動 | git switch <name> |
| 統合 | git merge <name> |
| 積み直し | git rebase <base> |
| ステージ解除 | git restore --staged <file> |
| 編集破棄 | git restore <file> |
| 打消しコミット | git revert <commit> |
| 退避 | git stash push |
| 参照移動履歴 | git reflog |
30分ハンズオン
練習用の新規フォルダで実行してください。本番リポジトリでは行わないでください。
-
git init -b mainで初期化する（対応バージョンのGitが必要）。 -
README.mdを作り、git add README.md→git commit -m "docs: 初回追加"を実行する。 -
git switch -c feature/readmeでブランチを作る。 - READMEに1行追加し、コミットする。
-
git switch main→git merge feature/readmeで取り込む。 -
git log --oneline --graph --allで履歴を確認する。 - READMEをもう一度編集し、
git diffで確認後、git restore README.mdで意図的に編集を破棄する。
最後に「どこに変更が存在するか」を自分の言葉で説明できれば、基礎は十分に身についています。
まとめ
Gitを使ううえで特に重要なのは、次の3点です。
- 操作前に
git statusで現在の状態を知る。 add・commit・pushの役割を区別する。- 公開済みの履歴を安易に書き換えず、取り消し方を選ぶ。
複雑なコマンドを暗記するよりも、差分・履歴・ブランチの状態を確認する習慣が、日常業務では役立ちます。