はじめに

普段からコードを書いていても、Git は「なんとなく使えている」状態のままでした。
add と commit の違いも、正直あいまいなままコマンドを打っていました。

今回、実際の開発作業の中で Git の基本的な流れを整理できたので、記録として残します。
「Git は使っているけれど、各コマンドが何をしているのかは説明できない」という方の参考になればうれしいです。

Git の基本的な流れ

ブランチ作成
    ↓
ファイル編集
    ↓
git add(コミット対象を選択)
    ↓
git commit(ローカルに記録)
    ↓
git push(GitHub に反映)
    ↓
PR 作成 → マージ

ここから、1 ステップずつ見ていきます。

1. ブランチを作る

git checkout -b feature/fix-something

-b は「新しいブランチを作成して、そのまま切り替える」オプションです。
作業はブランチ上で行い、main には直接触れないのが基本です。

なぜブランチを作るのか?

main を汚さずに作業できるからです。
途中で失敗しても、main は安全な状態のまま残ります。

2. ファイルを編集する

エディタでファイルを修正します。
この時点では、Git には何も記録されていません。

3. git add(ステージング)

git add ファイル名

「次のコミットにこのファイルを含める」と予約する操作です。

ポイント

git add していないファイルの変更は、コミットに含まれません
git add した後にさらに編集した場合は、もう一度 git add が必要です

# 複数ファイルを指定
git add ファイルA ファイルB

# 変更した全ファイルを追加(注意:意図しないファイルが含まれることもある)
git add .

4. git commit(ローカルに記録)

git commit -m "fix: グラフの色を修正する"

その時点のプロジェクト全体のスナップショットを保存します。
ゲームのセーブデータに近いイメージです。

コミットメッセージのプレフィックス

プレフィックス	意味
`feat:`	新機能
`fix:`	バグ修正・改善
`docs:`	ドキュメント
`test:`	テスト追加
`ci:`	CI/CD 関連

git commit はローカルにしか保存されません。
GitHub にはまだ反映されていない点に注意です。

5. git push(GitHub に反映)

# 初回(リモートにブランチを作成して紐付け)
git push -u origin feature/fix-something

# 2回目以降
git push

`origin` とは?

origin は、GitHub 上のリモートリポジトリにつけられた**名前(別名)**です。
git clone したときに、自動的にこの名前で登録されます。

つまり初回の git push -u origin feature/fix-something は、

「origin(GitHub)に feature/fix-something という同名のブランチを作り、ローカルのブランチと紐付ける」

という意味になります。
紐付けが済んでいるので、2回目以降は git push だけで同じブランチに反映されます。

6. PR(Pull Request)を作る

GitHub 上で PR を作成します。

「feature ブランチの変更を main に取り込んでいいですか?」

というリクエストです。

チーム開発では、他のメンバーがコードをレビューしてからマージします。
個人開発でも PR ベースで進めると、次のようなメリットがあります。

変更の記録が残る
作業単位が明確になる
差分が見やすい

7. マージする

GitHub の「Merge pull request」ボタンを押すと、feature ブランチの変更が main に取り込まれます。

main:    A → B
                \
feature:         C → D
                        ↓ マージ
main:    A → B → C → D

8. マージ後の後片付け

マージ済みのブランチは、ローカルから削除してスッキリさせます。

# main を最新に更新
git checkout main
git pull

# マージ済みブランチを削除
git branch -d feature/fix-something

マージ済みのブランチは、次のコマンドで確認できます。

git branch --merged main

つまずきやすい点:`-d` で怒られることがある

GitHub のマージ方法に Squash and merge を選んでいると、git branch -d が
「マージされていません」とエラーを出すことがあります。

Squash merge は、複数のコミットを 1 つにまとめて main に取り込む方式です。
そのため、ローカルのコミットと main 上のコミットが別物になり、Git が「マージ済み」と判断できません。

PR がマージされていることを確認したうえで、次のように強制削除します。

git branch -D feature/fix-something

コンフリクト(競合)が起きたら

複数のブランチで同じファイルの同じ箇所を編集すると、マージ時にコンフリクトが発生することがあります。
その場合、ファイルは次のような状態になります。

<<<<<<< 自分のブランチ
const a = 1;
=======
const a = 2;
>>>>>>> マージ元

<<<<<<< と >>>>>>> で囲まれた部分を手動で修正し、どちらの内容を使うかを選びます。
区切りの記号(<<<<<<<、=======、>>>>>>>)も、必ず削除してください。

修正後に git add → git commit でコンフリクト解消完了です。

よく使うコマンドまとめ

# 現在の状態を確認
git status

# 変更差分を確認
git diff

# コミット履歴を確認
git log --oneline

# ブランチ一覧
git branch

# リモートの変更を取得
git pull

まとめ

最初は add と commit の違いがわかりませんでしたが、整理すると次のようになります。

コマンド	やっていること
`add`	コミットに含めるファイルを予約する
`commit`	全体のスナップショットをローカルに保存する
`push`	GitHub に反映する

この 3 ステップが基本です。

暗記するより、実際に手を動かして、エラーを読みながら覚えていくのが一番身につくと感じました。