Git

Gitコマンドまとめ 〜基本コマンド・PRまでの流れ〜

1. Gitコマンド一覧

コマンド	意味	使う場面
git branch -M main	現在のブランチ名を main に変更	初期ブランチ名が master の場合など、main に統一したいとき
git remote add origin [e-mail]:ms819/リポジトリ名	リモートリポジトリ（GitHub）を登録	ローカルリポジトリとGitHubを紐づけるとき（初回のみ）
git status	現在の状態を確認	変更されたファイル、ステージング状況などを確認したいとき
git commit -m "メッセージ"	変更内容をコミット（履歴に保存）	ファイルをステージングした後、変更を記録するとき
git add ファイル名	ファイルをステージングエリアに追加	変更したファイルをコミット対象にするとき
git push origin ブランチ名	リモートリポジトリに変更を送信	コミットした内容をGitHubに反映したいとき
git diff	変更内容の差分を確認	変更した内容をコミット前に確認したいとき
git restore --staged ファイル名	ステージングエリアからファイルを外す	間違えてステージングしたファイルを取り消したいとき
git checkout ファイル名	ファイルの変更を元に戻す	まだコミットしていない変更を破棄したいとき
.gitignore	Gitで管理しないファイルを指定する設定ファイル	機密情報や不要なファイル（環境変数、ビルドファイルなど）を除外したいとき
git pull -r origin main	リモートの変更を取得してマージ（rebase）	最新の変更を取り込みたいとき。-r は --rebase の省略
git rebase --continue	リベースの途中で止まった処理を再開	コンフリクト解消後、リベースを続けるとき
git branch	ローカルのブランチ一覧を表示	どのブランチがあるか確認したいとき
git branch -M ブランチ名	現在のブランチ名を変更	ブランチ名を変更したいとき
git switch ブランチ名	指定したブランチに切り替え	別のブランチに移動して作業したいとき
git log	コミット履歴を表示	過去の変更履歴やコミットIDを確認したいとき
git log -p コミットid	特定のコミットの変更内容を表示	過去の変更内容を詳しく確認したいとき
git revert コミットid	特定のコミットを打ち消す新しいコミットを作成	過去の変更を安全に取り消したいとき（履歴を残したまま戻す）

---

2. 基本的なGitの使い方

Gitを使った開発では、基本的に

ファイルを変更
    ↓
git status
    ↓
git add
    ↓
git commit
    ↓
git push
    ↓
GitHub

という流れになります。

---

① 変更されたファイルを確認する

git status

現在のGitの状態を確認します。

例えば、

modified: app/models/user.rb
modified: app/controllers/users_controller.rb

のように表示されたら、

「この2ファイルが変更されている」

という意味です。

使う場面

• どのファイルを変更したか確認したい
• git add したファイルを確認したい
• コミット前に状態を確認したい
• Git操作中に何をすればいいかわからなくなった

迷ったらまず

git status

で現在の状態を確認するのがおすすめです。

---

3. git add ― コミットするファイルを選択する

例えば3つのファイルを変更したとします。

file1
file2
秘密のファイル

しかし、

file1
file2

だけをコミットしたい場合、

git add file1 file2

とします。

イメージとしては、

変更したファイル

file1
file2
秘密のファイル

       ↓ git add file1 file2

┌─────────────────┐
│ ステージングエリア │
│                 │
│ file1           │
│ file2           │
└─────────────────┘

秘密のファイル ← 入っていない

つまり git add は、

次のコミットに含めるファイルを選択する

操作です。

---

全ファイルをaddする場合

git add .

. は、

現在のディレクトリ以下

という意味です。

そのため、

git add .

を実行すると、多くの場合、変更したファイルをまとめてステージングします。

ただし、不要なファイルや機密情報まで含めないよう注意が必要です。

---

4. 間違えてaddした場合

例えば、

file1
file2
秘密のファイル

をすべてステージングしてしまったとします。

┌─────────────────┐
│ ステージングエリア │
│                 │
│ file1           │
│ file2           │
│ 秘密のファイル    │ ← 外したい！
└─────────────────┘

この場合、

git restore --staged 秘密のファイル

を実行します。

すると、

┌─────────────────┐
│ ステージングエリア │
│                 │
│ file1           │
│ file2           │
└─────────────────┘

秘密のファイル
    ↑
ステージングから外れる

となります。

つまり、

git restore --staged ファイル名

は、

「このファイルは今回のコミットに入れない！」

というときに使います。

---

5. git commit ― 変更を履歴として保存する

ステージングしたファイルをコミットします。

git commit -m "会社守るを修正"

イメージとしては、

変更したファイル
      ↓
git add
      ↓
┌───────────────┐
│ ステージング   │
│ file1         │
│ file2         │
└───────────────┘
      ↓
git commit
      ↓
Gitの変更履歴として保存

-m の後ろには、

何を変更したのか

を書きます。

例えば、

git commit -m "ログイン画面を追加"

git commit -m "ユーザー登録のバグを修正"

git commit -m "商品一覧のレイアウトを修正"

などです。

---

6. git push ― GitHubに変更を反映する

コミットしただけでは、変更は基本的に自分のPC上にあります。

GitHubへ送るために、

git push origin ブランチ名

を実行します。

例えば、

git push origin main

または作業ブランチなら、

git push origin feature/login

などです。

イメージは、

自分のPC

commit
  │
  │ git push
  ▼

GitHub

です。

つまり、

push = ローカルのコミットをGitHubへ送る

と考えるとわかりやすいです。

---

7. git pull ― GitHubの最新状態を取得する

チーム開発では、他の人もGitHubへ変更をpushします。

例えば、

自分
 │
 │ git push
 ▼

      GitHub
      ↙    ↘
   他の人   他の人

他の人がGitHubへ変更を反映した場合、自分のPCにも最新のコードを取り込む必要があります。

そこで使用するのが、

git pull

です。

今回使用しているコマンドでは、

git pull -r origin main

となります。

-r は、

--rebase

の省略です。

つまり、

git pull --rebase origin main

と同じです。

イメージとしては、

GitHub
   │
   │ git pull
   ▼
自分のPC

です。

---

8. コンフリクトとは？

git pull や rebase などをしたとき、

自分と他の人が同じ部分を別々に変更していると、Gitが

「どちらの変更を採用すればいいかわからない」

という状態になることがあります。

これが

コンフリクト（Conflict）

です。

例えば、

ローカル

console.log("Hello from the local branch!");

リモート

console.log("Hello from the remote branch!");

同じ行を別々に変更しているため、

ローカルの変更

        VS

リモートの変更

となり、Gitだけではどちらを残すべきか判断できません。

そのため、人間がコードを確認して修正します。

---

9. rebase中のコンフリクトを解消する

例えば、

git pull -r origin main

を実行してコンフリクトが発生した場合、

まず対象ファイルを修正します。

その後、

git add ファイル名

で修正済みのファイルをステージングします。

そして、

git rebase --continue

を実行します。

流れは、

git pull -r origin main
        ↓
コンフリクト発生
        ↓
ファイルを修正
        ↓
git add ファイル名
        ↓
git rebase --continue

となります。

git rebase --continue は、

「コンフリクトを直したのでrebaseの続きをしてください」

という意味です。

---

10. git diff ― 何を変更したか確認する

git diff

を実行すると、変更前と変更後の差分を確認できます。

例えば、

- console.log("Hello");
+ console.log("Hello World");

のように、

- 削除された内容
+ 追加された内容

を確認できます。

コミットする前に、

「自分は何を変更したんだっけ？」

となったときに便利です。

---

11. git checkout ファイル名 ― 変更を元に戻す

例えばファイルを編集して、

やっぱりこの変更全部いらない

となった場合、

git checkout ファイル名

で変更を元に戻すことができます。

変更前

   ↓ 編集

変更後

   ↓ git checkout ファイル名

変更前

ただし、未コミットの変更が消えるため注意が必要です。

---

12. .gitignore ― Gitで管理しないファイルを指定する

Gitでは、すべてのファイルをGitHubへアップロードすればいいわけではありません。

例えば、

.env
秘密鍵
APIキーを含むファイル
ログファイル
一時ファイル

などはGitで管理したくない場合があります。

そこで使用するのが、

.gitignore

です。

例えば、

.env
log/
tmp/
node_modules/

のように記述します。

イメージとしては、

プロジェクト

file1
file2
.env       ← Gitで管理しない
log/       ← Gitで管理しない
tmp/       ← Gitで管理しない

        ↓

.gitignoreで除外

となります。

---

13. ブランチとは？

ブランチは、

本体のコードから分岐して、安全に別の作業をするための仕組み

です。

例えば、

main
 │
 ├──────── feature/login
 │             │
 │             └ ログイン機能を開発
 │
 └──────── fix/bug
               │
               └ バグ修正

のように作業できます。

main を直接変更するのではなく、作業用ブランチを作って開発することで安全に作業できます。

---

14. ブランチ一覧を確認する

git branch

を実行すると、ローカルに存在するブランチを確認できます。

例えば、

* main
  feature/login
  fix/bug

と表示されます。

* が付いているブランチが、

現在自分がいるブランチ

です。

この場合は、

main

にいます。

---

15. ブランチを切り替える

git switch ブランチ名

を使用します。

例えば、

git switch feature/login

とすると、

main
  ↓
feature/login

へ移動します。

つまり、

git switch feature/login

は、

「feature/loginブランチで作業します」

というイメージです。

---

16. ブランチ名を変更する

git branch -M ブランチ名

例えば、

git branch -M main

とすると、現在のブランチ名を main に変更できます。

初期設定などで、

master

から

main

へ変更するときにも使用します。

---

17. GitHubとローカルリポジトリを紐づける

GitHubでリポジトリを作成したあと、

git remote add origin [e-mail]:ms819/リポジトリ名

を実行します。

これは、

自分のPCのGit
      ↕
GitHubリポジトリ

を紐づける設定です。

origin は、リモートリポジトリにつける名前です。

一般的にGitHubのリポジトリを

origin

と呼びます。

---

18. git log ― 過去の変更履歴を見る

git log

を実行すると、コミット履歴を確認できます。

例えば、

commit a1b2c3d4...
Author: ...
Date: ...

    ログイン機能を追加

commit e5f6g7h8...
Author: ...
Date: ...

    ユーザー登録を修正

のように表示されます。

ここから

commit ID

を取得できます。

イメージとしては、

現在
 │
 ● ログイン機能を追加
 │
 ● ユーザー登録を修正
 │
 ● 商品一覧を作成
 │
 ● プロジェクト作成
 │
過去

というGitの履歴を見るコマンドです。

---

19. 特定のコミットの変更内容を見る

git log -p コミットid

例えば、

git log -p a1b2c3d4

とすると、そのコミットで

どのファイルを変更したか
何を追加したか
何を削除したか

などを確認できます。

---

20. 過去のコミットを取り消す

git revert コミットid

を使用します。

例えば、

git revert a1b2c3d4

とすると、そのコミットの変更を打ち消す新しいコミットを作成します。

イメージとしては、

● A
│
● B ← 間違った変更
│
● C
│
● Bを取り消すコミット ← git revert

となります。

過去の履歴そのものを消すのではなく、

「この変更を取り消しました」という新しい履歴を作る

のがポイントです。

そのため、共有リポジトリでも比較的安全に変更を取り消せます。

---

21. GitHub上でも各ブランチの内容を確認できる

ブランチはターミナルだけで確認するものではありません。

GitHub上でも、

main
feature/login
fix/bug

など、それぞれのブランチに切り替えることができます。

イメージとしては、

GitHub

┌─────────────────────┐
│ Branch              │
│                     │
│ main                │
│ feature/login       │
│ fix/bug             │
└─────────────────────┘

確認したいブランチを選択すると、

そのブランチ時点のファイルやコード

をGitHub上で確認できます。

例えば、

main

ではまだログイン機能が存在しなくても、

feature/login

ではログイン機能のコードが存在する、

という状態も確認できます。

---

22. GitHubでプルリクエストを作成する

作業ブランチで開発が完了したら、その変更を main などへ反映するために

Pull Request（プルリクエスト / PR）

を作成します。

例えば、

main
  ↑
  │ Pull Request
  │
feature/login

という形です。

基本的な流れ

まず作業ブランチをGitHubへpushします。

git push origin feature/login

GitHubを開いて、作業ブランチ

feature/login

へ移動します。

その後、Pull Requestの作成ページへ進みます。

ここで重要なのが、

base
compare

です。

例えば、

base: main
compare: feature/login

とします。

これは、

feature/login
      ↓
     main

へ変更を反映するPull Requestです。

base

base: main

は、

マージ先

です。

compare

compare: feature/login

は、

変更を持ってくる作業ブランチ

です。

つまり、

base: main
        ↑
        │
compare: feature/login

という関係になります。

---

23. Gitの基本的な作業フロー

ここまでをまとめると、普段の開発では次のような流れになります。

main
 │
 │ 作業開始
 ↓
feature/login
 │
 │
 │ ファイルを編集
 ↓
git status
 │
 │
 ↓
git diff
 │
 │
 ↓
git add ファイル名
 │
 │
 ↓
git commit -m "ログイン機能を追加"
 │
 │
 ↓
git push origin feature/login
 │
 │
 ↓
GitHub
 │
 │
 ↓
Pull Request作成
 │
 │
 ↓
レビュー
 │
 │
 ↓
mainへマージ

---

24. チーム開発でのイメージ

GitHubを中心に考えると、

                GitHub
                  ↑
                  │ push
                  │
              自分のPC
                  
                GitHub
               ↙      ↘
          pull          pull
           ↓              ↓
       メンバーA       メンバーB

となります。

自分の変更をGitHubへ送るのが、

git push

GitHubの最新変更を自分のPCへ取得するのが、

git pull

です。

---

25. add・commit・pushの違い

最初はこの3つが特に混乱しやすいです。

操作	イメージ
git add	コミットするファイルを選ぶ
git commit	選んだ変更を履歴として保存
git push	保存した履歴をGitHubへ送る

図にすると、

ファイルを編集

      ↓

git add
「このファイルを記録する」

      ↓

ステージングエリア

      ↓

git commit
「変更を履歴として保存する」

      ↓

ローカルGit

      ↓

git push
「GitHubへ送る」

      ↓

GitHub

となります。

---

まとめ

Gitを使い始めたばかりの場合、まずは

git status

git add ファイル名

git commit -m "メッセージ"

git push origin ブランチ名

の基本的な流れを覚えると理解しやすいです。

特に、

add
↓
commit
↓
push

を、

コミットするファイルを選択
↓
変更履歴として保存
↓
GitHubへ送信

と理解すると整理しやすくなります。

また、チーム開発では、

作業ブランチ
↓
push
↓
Pull Request
↓
レビュー
↓
mainへマージ

という流れも非常によく使います。

そしてGit操作中に、

「今どういう状態だっけ？」

となった場合は、まず

git status

で現在の状態を確認するのがおすすめです。