はじめに
普段からコードを書いていても、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 ステップが基本です。
暗記するより、実際に手を動かして、エラーを読みながら覚えていくのが一番身につくと感じました。