Git入門早見表

Git早見表

Gitを使ったソースコード管理についての早見表です。

---

目次

1. Gitとは
2. 基本用語と略語
3. Gitが管理する4つの場所
4. 初期設定とリポジトリの準備
5. 基本的な作業の流れ
6. 状態・差分・履歴の確認
7. add・commit・push
8. ブランチ
9. マージ
10. コンフリクトの解消
11. リベース
12. リモートリポジトリとの連携
13. 変更・コミットの取り消し
14. 一時退避：stash
15. ファイル管理と.gitignore
16. タグ
17. プルリクエストを使う共同開発
18. よくあるエラーと確認方法
19. 安全に使うための注意点
20. 説明用まとめ
21. 最低限覚えるコマンド

---

1. Gitとは

Gitは、ファイルの変更履歴を記録・比較・共有するための分散型バージョン管理システムです。

• いつ変更したか
• 誰が変更したか
• 何を変更したか
• どの時点の状態へ戻したいか
• 複数人の変更をどう統合するか

を管理できます。

バージョン管理を使うメリット

• 過去の状態を確認できる
• 変更前後の差分を確認できる
• 機能ごとに作業を分けられる
• 複数人で同じプロジェクトを編集できる
• 不具合が入った変更を特定しやすい
• 安全に試行錯誤しやすい

GitとGitHubの違い

名前	種類	役割
Git	バージョン管理システム	PC上で変更履歴やブランチを管理する
GitHub	Gitホスティングサービス	Gitリポジトリをサーバー上で共有し、レビューなどを行う

Gitは履歴を管理する仕組みです。GitHubは、そのGitリポジトリをチームで共有するサービスです。

2. 基本用語と略語

主な略語

略語・用語	読み方・正式名	意味
VCS	ブイ・シー・エス／Version Control System	バージョン管理システム
DVCS	ディー・ブイ・シー・エス／Distributed Version Control System	分散型バージョン管理システム
CLI	シー・エル・アイ／Command Line Interface	コマンドで操作する画面・方式
GUI	ジー・ユー・アイ／Graphical User Interface	ボタンや画面で操作する方式
SCM	エス・シー・エム／Source Code Management	ソースコード管理
URL	ユー・アール・エル／Uniform Resource Locator	リモートリポジトリなどの場所を示す文字列
HTTPS	エイチ・ティー・ティー・ピー・エス	暗号化された通信方式
SSH	エス・エス・エイチ／Secure Shell	鍵認証などで安全に接続する方式
PR	ピー・アール／Pull Request	変更の取り込みを依頼し、レビューする仕組み
CI	シー・アイ／Continuous Integration	継続的インテグレーション
SHA	シャ／Secure Hash Algorithm	コミットなどを識別するハッシュに関係する用語

Gitの主な用語

用語	読み方	意味
repository	リポジトリ	ファイルと変更履歴を管理する場所
local repository	ローカルリポジトリ	自分のPCにあるリポジトリ
remote repository	リモートリポジトリ	サーバー上にあり、チームで共有するリポジトリ
working tree	ワーキングツリー	現在編集しているファイル群
staging area	ステージングエリア	次のコミットへ含める変更を選ぶ場所
index	インデックス	ステージングエリアの別名
commit	コミット	選択した変更を履歴として記録すること・記録した単位
commit ID	コミット・アイディー	コミットを識別するハッシュ値
branch	ブランチ	履歴から作業を分岐させるための参照
merge	マージ	別ブランチの変更を現在のブランチへ統合すること
conflict	コンフリクト	Gitだけでは変更を自動統合できない状態
rebase	リベース	コミットの土台を付け替え、履歴を並べ直す操作
tag	タグ	特定のコミットへ付ける固定の目印
clone	クローン	リモートリポジトリを履歴ごと手元へ複製すること
fetch	フェッチ	リモートの更新情報を取得すること
pull	プル	リモートの更新を取得し、現在のブランチへ統合すること
push	プッシュ	ローカルのコミットをリモートへ送ること
origin	オリジン	リモートリポジトリに付ける慣例的な名前
HEAD	ヘッド	現在チェックアウトしているコミットやブランチを示す参照
snapshot	スナップショット	ある時点のファイル状態の記録
diff	ディフ／difference	変更前後の差分

コミットID

4c321af6e0c8...

コミットIDは、各コミットを識別する値です。通常は先頭の数文字だけでも、リポジトリ内で一意なら指定できます。

git show 4c321af

Gitの画面では「SHA」「ハッシュ」「コミットID」と呼ばれることがあります。

HEADの表し方

表記	意味
HEAD	現在位置
HEAD~1	現在位置の1つ前のコミット
HEAD~2	現在位置の2つ前のコミット
main	mainブランチが指すコミット
origin/main	最後に取得したリモート側mainの状態を示す参照

一言：
コミットは履歴の1単位、ブランチは作業を分けるための目印、HEADは現在作業している位置を表します。

---

3. Gitが管理する4つの場所

Git操作は、変更が「今どの場所にあるか」を意識すると理解しやすくなります。

1. ワーキングツリー
   現在編集しているファイル
          │ git add
          ▼
2. ステージングエリア（インデックス）
   次のコミットへ含める変更
          │ git commit
          ▼
3. ローカルリポジトリ
   自分のPCに保存されたコミット履歴
          │ git push
          ▼
4. リモートリポジトリ
   GitHubなどに保存された共有履歴

ファイルの主な状態

状態	読み方	意味
untracked	アントラックト／未追跡	Gitがまだ管理していない新規ファイル
modified	モディファイド／変更済み	管理中のファイルを編集した状態
staged	ステージド	次のコミットへ含める変更として選択済み
committed	コミッテッド	ローカルの履歴へ記録済み
pushed	プッシュ済み	リモートへ送信済み

重要な考え方

git addは、ファイル名を永久に登録する操作ではなく、その時点のファイル内容を次のコミット候補へ載せる操作です。

git add sample.py

この後にsample.pyを再編集した場合、追加編集分も含めるには、もう一度git add sample.pyを実行します。

一言：
編集しただけではコミットされません。addで変更を選び、commitでローカル履歴に保存し、pushで共有します。

---

4. 初期設定とリポジトリの準備

Gitのバージョン確認

git --version

ユーザー名・メールアドレスの設定

git config --global user.name "Cake"
git config --global user.email "[e-mail]"

設定内容はコミットの作成者情報として使われます。業務では、会社指定の名前・メールアドレスを確認します。

設定を確認する

git config --global --list
git config --show-origin --list

• --global：PC上の自分用設定
• --local：現在のリポジトリだけに適用する設定
• --show-origin：設定がどのファイルから読み込まれたか表示

特定リポジトリだけ別のメールアドレスを使う例：

git config --local user.email "[e-mail]"

既存リポジトリを取得する：clone

git clone <リポジトリURL>
cd <作成されたフォルダ名>

git clone <リポジトリURL> 任意のフォルダ名

cloneすると、通常は次のものが準備されます。

• ファイル
• コミット履歴
• ローカルブランチ
• originという名前のリモート設定

新しいフォルダをGit管理する：init

mkdir sample-project
cd sample-project
git init

リモートリポジトリを登録する場合：

git remote add origin <リポジトリURL>

リポジトリか確認する

git status

Git管理外のフォルダでは、次のようなエラーになります。

fatal: not a git repository

一言：
既存の共有リポジトリを使うときはclone、新規フォルダをGit管理するときはinitを使います。

---

5. 基本的な作業の流れ

既存プロジェクトで機能ブランチを作る例

# 1. リポジトリへ移動
cd sample-project

# 2. 現在の状態を確認
git status

# 3. mainへ移動
git switch main

# 4. リモートの最新状態を反映
git pull

# 5. 作業用ブランチを作成して移動
git switch -c feature/login

# 6. ファイルを編集した後、状態と差分を確認
git status
git diff

# 7. コミットへ含める変更を選ぶ
git add src/login.py

# 8. ステージ済みの差分を確認
git diff --staged

# 9. ローカル履歴へ記録
git commit -m "Add login validation"

# 10. リモートへ送信
git push -u origin feature/login

その後、GitHubの画面でプルリクエストを作成します。

2回目以降の更新

# 編集後
git status
git diff
git add src/login.py
git diff --staged
git commit -m "Fix login error message"
git push

最初のpushで-uを指定すると、ローカルブランチとリモートブランチの追跡関係が設定されます。その後は、通常git pushだけで送信できます。

作業前・コミット前・push前の確認

git status
git diff
git diff --staged
git log --oneline -5

一言：
最新の基準ブランチから作業ブランチを作り、差分を確認してコミットし、リモートへpushしてレビューを依頼します。

---

6. 状態・差分・履歴の確認

Gitでは、変更や取り消しを行う前に確認コマンドを使うことが重要です。

状態を確認する：status

git status

短く表示する場合：

git status -sb

-sはshort、-bはbranchの情報を表示します。

ステージ前の差分：diff

git diff

特定ファイルだけ確認：

git diff src/login.py

git diffは、主にワーキングツリーとステージングエリアの差分を表示します。未追跡ファイルの内容は通常表示されないため、git statusも併用します。

ステージ済みの差分

git diff --staged

--cachedも同じ用途で使えます。

git diff --cached

これは「次のコミットに何が入るか」を確認するコマンドです。

コミット履歴：log

git log

1行表示：

git log --oneline

ブランチの分岐も表示：

git log --oneline --graph --decorate --all

最近5件だけ表示：

git log --oneline -5

特定ファイルの履歴：

git log --oneline -- src/login.py

コミット内容を見る：show

git show HEAD
git show <コミットID>

ファイル内容を表示する例：

git show HEAD:src/login.py

ブランチ間の差分

git diff main..feature/login

誰がどの行を変更したか：blame

git blame src/login.py

blameは原因追及のために人を責めるものではなく、変更の背景となるコミットを探すために使います。

一言：
statusで状態、diffで変更内容、logで履歴、showで特定コミットの詳細を確認します。

---

7. add・commit・push

3つの違い

コマンド	変更の移動先	役割
git add	ワーキングツリー → ステージングエリア	次のコミットへ含める変更を選ぶ
git commit	ステージングエリア → ローカルリポジトリ	変更をローカル履歴へ記録する
git push	ローカルリポジトリ → リモートリポジトリ	コミットを共有先へ送る

ファイルをステージする

git add src/login.py

複数ファイル：

git add src/login.py tests/test_login.py

現在のディレクトリ以下の変更をまとめて追加：

git add .

すべてを機械的に追加すると、不要なファイルや秘密情報まで含める可能性があります。必ず次を確認します。

git status
git diff --staged

変更の一部だけステージする

git add -p

-pはpatch（パッチ）単位で、同じファイル内の変更を分けて選択できます。

主な選択肢：

入力	意味
y	この変更部分をステージする
n	ステージしない
s	さらに細かく分割する
q	終了する
?	ヘルプを表示する

コミットする

git commit -m "Add login validation"

エディタを開いてメッセージを書く場合：

git commit

コミットの考え方

良いコミットは、次の特徴を持ちます。

• 1つの目的に絞る
• 後から見て変更理由が分かる
• 不要なファイルを含めない
• ビルドやテストができる状態を意識する
• チームのメッセージ規約に従う

例：

Add login validation
Fix task registration wait condition
Update Git cheat sheet

リモートへpushする

git push -u origin feature/login

• origin：リモート名
• feature/login：送信するブランチ名
• -u：追跡関係を設定するオプション

2回目以降：

git push

一言：
addはコミット候補の選択、commitはローカルへの記録、pushはリモートへの共有です。

---

8. ブランチ

ブランチは、現在の履歴から作業を分岐させるための参照です。機能追加や不具合修正を、基準ブランチへ直接混ぜずに進められます。

main        A──B────────E
                  ＼    ／
feature/login      C──D

ブランチ一覧

git branch

現在のブランチには*が付きます。

リモートブランチも含める：

git branch -a

追跡先も確認：

git branch -vv

ブランチを作成して移動

git switch -c feature/login

• switch：ブランチを切り替える
• -c：新しいブランチを作成する

作成だけ行う場合：

git branch feature/login

既存ブランチへ移動

git switch main

従来の書き方も利用できます。

git checkout main
git checkout -b feature/login

checkoutは複数の役割を持つため、この資料ではブランチ操作にswitch、ファイル復元にrestoreを主に使用します。

リモートブランチからローカルブランチを作る

git fetch origin
git switch --track origin/feature/login

ローカル名を指定する場合：

git switch -c feature/login origin/feature/login

ブランチ名を変更する

現在のブランチ名を変更：

git branch -m 新しいブランチ名

ブランチを削除する

マージ済みブランチを安全に削除：

git branch -d feature/login

強制削除：

git branch -D feature/login

-Dは未統合のコミットがあっても削除するため、通常は-dを優先します。

リモートブランチを削除：

git push origin --delete feature/login

ブランチ名の例

feature/login
feature/task-registration
fix/login-error
docs/git-cheatsheet

実際の命名規則は、案件やチームのルールを優先します。

Detached HEAD

ブランチではなく特定コミットへ直接移動すると、Detached HEAD（デタッチド・ヘッド）状態になることがあります。

git switch --detach <コミットID>

この状態で作成したコミットを残したい場合は、ブランチを作ります。

git switch -c recovery/work

一言：
ブランチは履歴をコピーするというより、コミットを指す軽量な目印です。機能ごとに作業を分け、完成後に統合します。

---

9. マージ

マージは、別ブランチの変更を現在のブランチへ統合する操作です。

基本手順

feature/loginをmainへ統合する例：

# 1. 取り込み先のmainへ移動
git switch main

# 2. mainを最新化
git pull

# 3. feature/loginを現在のmainへ取り込む
git merge feature/login

git merge Aは、現在いるブランチへAを取り込む操作です。取り込み先を間違えないように、先にgit statusやgit branch --show-currentで確認します。

現在のブランチ名を確認

git branch --show-current

Fast-forward

基準ブランチ側に新しい変更がない場合、ブランチの参照を前へ進めるだけで統合できます。これをFast-forward（ファストフォワード）と呼びます。

統合前: main A──B
                  ＼
feature             C──D

統合後: main A──B──C──D

Merge commit

両方のブランチが進んでいる場合は、変更を統合するマージコミットが作成されることがあります。

main        A──B──────E
                  ＼  ／
feature             C──D

明示的にマージコミットを作る方法：

git merge --no-ff feature/login

マージ方式はチームの運用ルールを優先します。

マージを中止する

コンフリクトなどが発生し、マージ開始前へ戻したい場合：

git merge --abort

一言：
マージは、現在のブランチへ別ブランチの変更を統合する操作です。まず取り込み先へ移動してから実行します。

---

10. コンフリクトの解消

Gitが変更を自動統合できない場合、コンフリクトが発生します。

主な原因：

• 同じファイルの同じ行を別々に変更した
• 一方がファイルを編集し、もう一方が削除した
• ファイル名変更と内容変更が競合した

コンフリクト発生時の流れ

# 1. 競合ファイルを確認
git status

# 2. ファイルを開いて、残す内容を決める

# 3. 競合マーカーを削除し、完成形へ編集

# 4. 解消済みとしてステージ
git add <解消したファイル>

# 5. 状態を確認
git status

# 6. マージを完了
git commit

次のコマンドでもマージを続行できます。

git merge --continue

コンフリクトマーカー

<<<<<<< HEAD
現在のブランチ側の内容
=======
取り込もうとしているブランチ側の内容
>>>>>>> feature/login

最終的に残したい内容へ編集し、次のマーカーをすべて削除します。

<<<<<<<
=======
>>>>>>>

「上か下のどちらか一方を必ず選ぶ」とは限りません。両方を残したり、新しい内容へ書き直したりする場合もあります。

解消前へ戻す

git merge --abort

解消後の確認

git status
git diff --cached --check

git diff --cached --checkは、ステージ済み変更に残った競合マーカーや空白エラーの確認に役立ちます。ステージ前ならgit diff --checkを使います。

その後、必要なビルドやテストを実行します。

一言：
コンフリクトはエラーというより、Gitが「どの変更を残すか判断できない」と人へ確認している状態です。完成形を手作業で決めてコミットします。

---

11. リベース

リベースは、現在のブランチのコミットを別の土台へ付け替える操作です。

リベース前
main        A──B──C
               ＼
feature          D──E

リベース後
main        A──B──C
                  ＼
feature             D'──E'

DとEを新しいmainの後ろへ作り直すため、コミットIDはD'とE'へ変わります。

基本例

git switch feature/login
git fetch origin
git rebase origin/main

コンフリクトが起きた場合

# 1. 競合ファイルを編集

# 2. 解消済みとして追加
git add <ファイル>

# 3. 続行
git rebase --continue

中止：

git rebase --abort

マージとリベースの違い

操作	特徴	履歴
merge	2つの履歴を統合する	分岐の形を残しやすい
rebase	コミットの土台を付け替える	直線的に整理しやすい

リベースの注意

• コミットIDが変わる
• 他の人が利用中の共有コミットを勝手にリベースしない
• push済みブランチの履歴変更は、チームルールを確認する
• 強制pushが必要になる場合でも、自己判断で実行しない

基本原則：他の人が作業の土台にしている可能性がある履歴は、勝手に書き換えません。

一言：
マージは履歴を合流させ、リベースは自分のコミットを新しい土台の上へ並べ直します。リベースは履歴を書き換えるため、共有後は注意が必要です。

---

12. リモートリポジトリとの連携

リモート設定を確認

git remote -v

詳細を確認：

git remote show origin

originは特別な予約語ではなく、最初のリモートへ慣例的に付けられる名前です。

リモートを追加

git remote add origin <リポジトリURL>

URLを変更

git remote set-url origin <新しいリポジトリURL>

fetch・pull・pushの違い

コマンド	方向	主な動作
git fetch	リモート → ローカル	リモートの更新情報を取得する。作業中のファイルは通常変更しない
git pull	リモート → 現在のブランチ	fetch後、現在のブランチへ変更を統合する
git push	ローカル → リモート	ローカルコミットをリモートへ送る

fetch

git fetch origin

取得後に差分を確認：

git log --oneline HEAD..origin/main
git diff HEAD..origin/main

不要になったリモート追跡ブランチを整理しながら取得：

git fetch --prune

--prune（プルーン）は、リモートですでに削除されたブランチに対応する古い参照を整理します。

pull

git pull

git pullは、まずfetchし、その後に設定やオプションに応じて変更を統合します。環境によってmerge、rebase、fast-forward onlyなどの方針が異なるため、案件のルールを確認します。

Fast-forwardできる場合だけ更新する例：

git pull --ff-only

push

git push -u origin feature/login

ローカルブランチと追跡先を確認

git branch -vv

origin/mainとは

origin/mainはリモートサーバー上のファイルを直接見ているものではなく、最後にfetchまたはpullした時点のリモートmainを表すローカル側の参照です。

最新情報へ更新するには：

git fetch origin

一言：
fetchは更新情報だけ取得し、pullは取得後に現在のブランチへ統合し、pushは自分のコミットをリモートへ送ります。

---

13. 変更・コミットの取り消し

取り消し操作は、「どこまで反映済みか」で使い分けます。

先に確認すること

git status
git diff
git diff --staged
git log --oneline -5

状態別の早見表

状態	目的	主なコマンド
編集したが未ステージ	作業中の変更を破棄	git restore <file>
ステージ済み	ステージだけ解除	git restore --staged <file>
直前のローカルコミット	内容やメッセージを修正	git commit --amend
共有済みコミット	逆向きの新規コミットで打ち消す	git revert <commit>
ローカル履歴を戻す	HEADを過去へ移動	git reset
誤って履歴を動かした	過去のHEAD位置を探す	git reflog

未ステージの変更を破棄：restore

git restore src/login.py

追跡中の指定ファイルをステージングエリアの内容へ戻します。未コミットの変更は失われるため、差分確認後に実行します。未追跡ファイルは対象外です。

すべての追跡ファイルを戻す例：

git restore .

ステージだけ解除

git restore --staged src/login.py

ファイルの編集内容は残り、次のコミット候補からだけ外れます。

過去のコミットからファイルを復元

git restore --source=<コミットID> -- src/login.py

--は、ここから後ろがファイルパスであることを明示します。

直前のコミットメッセージを修正

git commit --amend -m "Correct commit message"

直前のコミットへファイルを追加し忘れた場合

git add <追加し忘れたファイル>
git commit --amend --no-edit

--amendは直前のコミットを作り直すため、コミットIDが変わります。原則として、まだ共有していないコミットに使用します。

共有済みコミットを安全に打ち消す：revert

git revert <コミットID>

revertは、指定コミットの変更を打ち消す新しいコミットを作ります。既存履歴を消さないため、共有済み履歴では比較的安全です。

履歴を移動する：reset

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

モード	HEAD	ステージ	ワーキングツリー
--soft	戻す	変更を残す	変更を残す
--mixed	戻す	ステージを解除	変更を残す
--hard	戻す	戻す	変更を破棄する

--mixedはモード省略時の既定です。

git reset HEAD~1

reset --hardの注意

git reset --hard <コミットID>

追跡中ファイルの未コミット変更を失う可能性があります。共有済み履歴や業務リポジトリでは、自己判断で実行しません。

restore・reset・revertの違い

コマンド	主な対象	履歴を書き換えるか	主な用途
restore	ファイル・ステージ	通常は書き換えない	未コミット変更やステージを戻す
reset	HEAD・ステージ・ファイル	書き換える場合がある	ローカル履歴を過去へ動かす
revert	既存コミットの効果	書き換えない	逆変更の新規コミットを作る

操作履歴を確認：reflog

git reflog

resetやブランチ移動前のコミットを探すときに役立ちます。

見つけたコミットから復旧ブランチを作る例：

git switch -c recovery/restore <コミットID>

未追跡ファイルを削除：clean

最初に削除対象だけ確認します。

git clean -nd

実際に削除：

git clean -fd

• -n：dry run（ドライラン）。実行せず対象を表示
• -f：force（フォース）。削除を実行
• -d：未追跡ディレクトリも対象

git cleanで削除した未追跡ファイルは、Git履歴から復元できません。

一言：
未コミット変更はrestore、共有前のローカル履歴調整はresetやamend、共有済みコミットの打ち消しはrevertを基本に考えます。

---

14. 一時退避：stash

stash（スタッシュ）は、未コミットの変更を一時退避し、ワーキングツリーを整理する機能です。

変更を退避

git stash push -m "ログイン画面の作業途中"

未追跡ファイルも含める：

git stash push -u -m "作業途中"

-uはuntracked（未追跡）ファイルを含めます。

一覧を確認

git stash list

stash@{0}: On feature/login: ログイン画面の作業途中

内容を確認

git stash show -p stash@{0}

最新の退避を戻す

git stash pop

popは変更を適用し、正常に適用できた場合は通常stash一覧から削除します。

一覧へ残したまま適用

git stash apply stash@{0}

削除

git stash drop stash@{0}

すべて削除：

git stash clear

利用場面

• 作業途中に別ブランチへ移動する必要がある
• pull前に一時的に作業ツリーをきれいにしたい
• 緊急修正へ切り替えたい

注意

• 長期間の保管場所として使わない
• stashにもコンフリクトが起こることがある
• 重要な作業は、可能なら小さなコミットや作業ブランチで残す
• stash clearは全件削除なので慎重に使う

一言：
stashは、まだコミットしたくない作業を一時的に引き出しへしまい、後から戻す機能です。

---

15. ファイル管理と.gitignore

.gitignore

.gitignore（ギットイグノア）は、Gitの追跡対象にしないファイルやディレクトリのパターンを指定するファイルです。

例：

# Pythonのキャッシュ
__pycache__/
*.pyc

# 仮想環境
.venv/
venv/

# 環境変数・秘密情報
.env

# ログ
*.log

# IDE設定
.idea/

# OSが作るファイル
.DS_Store
Thumbs.db

パターンの例

記述	意味
*.log	拡張子.logを無視
build/	buildディレクトリを無視
/temp/	リポジトリ直下のtempだけ無視
secret.txt	secret.txtを無視
!sample.env	それまでの無視対象から例外として追跡可能にする

無視されているか確認

git check-ignore -v .env

すでに追跡済みのファイル

.gitignoreへ追加しても、すでにコミット済みのファイルは自動では追跡解除されません。

ローカルには残し、Gitの追跡だけ解除する例：

git rm --cached .env

ディレクトリの場合：

git rm -r --cached .venv

その後、.gitignoreと追跡解除をコミットします。

パスワードやトークンをすでにpushした場合、追跡解除だけでは過去履歴から消えません。認証情報を失効・再発行し、会社や案件の手順に従って対応します。

Git管理下のファイルを削除

git rm old_file.txt

ローカルには残して追跡だけ解除：

git rm --cached old_file.txt

ファイル名を変更・移動

git mv old_name.txt new_name.txt

通常のOS操作で移動してからgit add -Aしても、Gitが内容から移動を検出する場合があります。

空ディレクトリ

Gitは空ディレクトリそのものを追跡しません。必要な場合は、.gitkeepなどの空ファイルを置く慣例があります。

logs/.gitkeep

.gitkeepはGitの特別な機能ではなく、単なる慣例的なファイル名です。

一言：
.gitignoreは、生成ファイルや秘密情報などを誤ってGit管理へ含めないための除外ルールです。

---

16. タグ

タグは、リリースなどの特定コミットへ付ける固定の目印です。

ブランチは作業とともに移動しますが、タグは通常同じコミットを指し続けます。

タグ一覧

git tag

注釈付きタグを作成

git tag -a v1.0.0 -m "Release version 1.0.0"

現在以外のコミットへ付ける：

git tag -a v1.0.0 <コミットID> -m "Release version 1.0.0"

タグの詳細

git show v1.0.0

リモートへ送る

git push origin v1.0.0

すべてのタグを送る：

git push origin --tags

ローカルタグを削除

git tag -d v1.0.0

リモートタグを削除：

git push origin --delete v1.0.0

タグの命名・削除は、リリース管理へ影響するためチームルールを優先します。

一言：
タグは、リリース版など後から見つけたい特定コミットへ付ける固定のラベルです。

---

17. プルリクエストを使う共同開発

Pull Request（プルリクエスト、PR）は、作業ブランチの変更を基準ブランチへ取り込むよう依頼し、レビューや確認を行う仕組みです。

PRはGitそのもののコマンドではなく、GitHubなどのサービスが提供する共同開発機能です。

一般的な流れ

1. mainを最新化
2. 作業ブランチを作成
3. 実装・テスト
4. add・commit
5. 作業ブランチをpush
6. PRを作成
7. レビュー指摘へ対応
8. 承認後にmerge
9. ローカルmainを更新
10. 不要な作業ブランチを削除

コマンド例

# 作業開始
git switch main
git pull
git switch -c docs/git-cheatsheet

# 編集後
git status
git diff
git add git_cheatsheet.md
git diff --staged
git commit -m "Add Git cheat sheet"
git push -u origin docs/git-cheatsheet

PR作成後に修正した場合：

git add git_cheatsheet.md
git commit -m "Update merge conflict explanation"
git push

同じブランチへpushすれば、通常は既存PRへコミットが追加されます。

マージ後のローカル整理

git switch main
git pull
git branch -d docs/git-cheatsheet
git fetch --prune

レビュー前の確認

• PRの向きが正しいか
  • base：取り込み先
  • compare / head：作業ブランチ
• 不要なファイルが含まれていないか
• 秘密情報が含まれていないか
• ビルド・テストが成功するか
• PRの説明に変更内容・確認方法・影響範囲があるか
• 課題番号や命名規則が案件ルールに合っているか

一言：
PRは、変更をすぐ本流へ入れず、内容を共有・レビューしてから安全に統合するための仕組みです。

---

18. よくあるエラーと確認方法

fatal: not a git repository

fatal: not a git repository

主な原因

• Git管理外のフォルダにいる
• リポジトリの親フォルダへ移動している
• .gitディレクトリがない

確認

pwd
ls -la
git status

Windows PowerShellでは：

Get-Location
Get-ChildItem -Force

正しいリポジトリへcdで移動します。

---

nothing to commit

nothing to commit, working tree clean

変更がない、すでにコミット済み、または対象ファイルを保存していない可能性があります。

git status
git log --oneline -3

---

pathspec ... did not match

error: pathspec 'feature/login' did not match any file(s) known to git

主な原因

• ブランチ名やファイル名の入力ミス
• まだfetchしていない
• 対象ブランチが存在しない

確認

git branch -a
git fetch origin
git branch -a

---

non-fast-forward・rejected

! [rejected] ... (non-fast-forward)

リモート側に、自分のローカルにはないコミットがある可能性があります。

git fetch origin
git status
git log --oneline --graph --decorate --all

その後の統合方法は、merge・rebaseなどチームルールに従います。

エラーを消すためだけにgit push --forceを実行しません。

---

local changes would be overwritten

Your local changes would be overwritten by checkout/merge

未コミット変更が、ブランチ切り替えやマージで上書きされる可能性があります。

対応候補：

# 変更をコミットする
git add <file>
git commit -m "Save work in progress"

# または一時退避する
git stash push -u -m "作業途中"

# 不要な変更なら、確認後に破棄する
git restore <file>

---

コンフリクト

CONFLICT (content): Merge conflict in ...

git status

競合ファイルを編集し、マーカーを削除してから：

git add <file>
git commit

中止する場合：

git merge --abort

---

push先・ブランチが分からない

git remote -v
git branch -vv
git status -sb

---

認証エラー

Authentication failed
Permission denied

確認事項

• リポジトリURLが正しいか
• HTTPS・SSHのどちらを使う運用か
• アクセス権限があるか
• トークンやSSH鍵の有効期限・登録状態
• 会社指定の認証手順があるか

認証情報をコマンドやチャットへそのまま貼り付けません。

---

Detached HEADになった

git status

履歴を見るだけなら、元のブランチへ戻ります。

git switch main

作成したコミットを残すなら、移動前にブランチを作ります。

git switch -c recovery/work

---

何をすればよいか分からないとき

次を順番に確認すると、現在位置と差分を整理できます。

git status
git branch -vv
git remote -v
git diff
git diff --staged
git log --oneline --graph --decorate --all -15

エラーメッセージは、省略せず先頭から末尾まで確認します。業務チャットへ貼る場合は、リポジトリURL、ユーザー名、トークン、社内情報などを伏せ、案件の共有ルールに従います。

---

19. 安全に使うための注意点

コミット前に必ず見る

git status
git diff
git diff --staged

秘密情報をコミットしない

含めてはいけない例：

• パスワード
• APIキー
• アクセストークン
• 秘密鍵
• .env
• 個人情報
• 顧客データ
• 社外公開不可のログや画面キャプチャ

秘密情報をpushした場合は、単に削除コミットを作るだけでなく、認証情報の失効・再発行と、所属先の報告手順が必要です。

危険度が高い操作

次は、理解せずに実行しません。

git reset --hard
git clean -fd
git branch -D <branch>
git push --force
git rebase <共有ブランチ>

特に共有リポジトリでは、現場ルールや担当者の指示を確認します。

force push

履歴を書き換えたブランチを送るときに必要になる場合がありますが、他の人のコミットを失わせる可能性があります。

どうしてもチームルール上必要な場合は、単純な--forceより保護確認を行う--force-with-leaseが使われることがあります。

git push --force-with-lease

ただし、これも強制pushです。自己判断で実行しません。

mainへ直接コミットしない

チームでブランチ運用をしている場合、通常は作業ブランチを作成し、PR経由で統合します。

git switch main
git pull
git switch -c feature/example

変更は小さく分ける

• 1コミット1目的を意識する
• 整形だけの変更と機能変更を可能なら分ける
• 無関係なファイルを含めない
• 大量変更前にブランチと状態を確認する

エラー時にすぐ上書きしない

エラーが出たら、まず現在の状態を残して確認します。

git status
git log --oneline --graph --decorate --all -15
git reflog -15

一言：
Gitでは、多くの事故が「確認せずに破棄・強制操作をしたこと」で起こります。まずstatusとdiffを確認し、共有履歴は勝手に書き換えません。

---

20. まとめ

Git

Gitは、ファイルの変更履歴を記録する分散型バージョン管理システムです。
過去の状態や差分を確認でき、ブランチで作業を分け、複数人の変更を統合できます。

GitとGitHubの違い

Gitは変更履歴を管理する仕組みです。
GitHubは、Gitリポジトリをサーバー上で共有し、プルリクエストやレビューを行うサービスです。

add・commit・push

addは次のコミットへ入れる変更を選ぶ操作、commitはローカル履歴へ記録する操作、pushはそのコミットをリモートへ送る操作です。

編集 → add → commit → push

ブランチ

ブランチは、作業を本流から分けるための履歴上の目印です。
機能追加や修正を別ブランチで行い、完成後にmainなどへ統合します。

マージ

マージは、現在のブランチへ別ブランチの変更を取り込む操作です。
取り込み先へ移動してから、取り込みたいブランチを指定します。

コンフリクト

コンフリクトは、同じ場所への異なる変更などにより、Gitが自動で統合結果を決められない状態です。
人が最終的な内容を決め、競合マーカーを削除してコミットします。

fetch・pull・push

fetchはリモートの更新情報だけ取得し、pullは取得後に現在のブランチへ統合します。
pushは、自分のローカルコミットをリモートへ送ります。

restore・reset・revert

restoreは主に未コミットのファイルやステージを戻します。
resetはローカル履歴の位置を動かし、revertは共有済みコミットを新しい逆変更コミットで打ち消します。

PR

PRは、作業ブランチの変更を基準ブランチへ取り込むよう依頼し、レビューや自動テストを通してから統合する仕組みです。
PRはGitコマンドではなく、GitHubなどのサービスの機能です。

Gitの一連の流れ

まず基準ブランチを最新化し、作業ブランチを作ります。
実装後にstatusとdiffで確認し、add、commit、pushを行います。
その後PRを作成し、レビューとテストを経て基準ブランチへマージします。

---

21. 最低限覚えたいコマンド

作業開始

git status
git switch main
git pull
git switch -c feature/example

編集後

git status
git diff
git add <ファイル名>
git diff --staged
git commit -m "変更内容"
git push -u origin feature/example

2回目以降

git status
git diff
git add <ファイル名>
git diff --staged
git commit -m "変更内容"
git push

履歴確認

git log --oneline --graph --decorate --all
git show <コミットID>

ブランチ確認

git branch
git branch -a
git branch -vv

リモート確認

git remote -v
git fetch origin
git status -sb

ステージを解除

git restore --staged <ファイル名>

未コミット変更を破棄

git diff <ファイル名>
git restore <ファイル名>

一時退避

git stash push -u -m "作業途中"
git stash list
git stash pop

困ったときの確認セット

git status
git branch -vv
git remote -v
git diff
git diff --staged
git log --oneline --graph --decorate --all -15
git reflog -15

コマンドのヘルプ

git help <コマンド名>
git <コマンド名> -h

例：

git help status
git switch -h

---

最重要ポイント

1. 作業前に現在のブランチと状態を確認する
2. コミット前にstatus・diff・diff --stagedを確認する
3. addは選択、commitはローカル保存、pushは共有
4. mergeは取り込み先ブランチへ移動してから実行する
5. コンフリクトは完成形を人が判断する
6. 共有済み履歴を勝手に書き換えない
7. reset --hard・clean・force pushは慎重に扱う
8. パスワード・トークン・顧客情報をコミットしない
9. 現場のブランチ・PR・マージ規約を優先する
10. 分からないときは、まずgit statusで現在地を確認する