BEGINNERS' TIPS

初学者あるある編

Gitで最初にハマるところ

大丈夫、みんな最初はこうだった

コミットの悩みメッセージの書き方あるあるミス実践パターン

→ キーで次へ

この編の全体像

ゴール: Gitを使い始めたときの不安やモヤモヤを解消し、自信を持ってcommitできるようになる

Section 1

コミットの悩み

いつcommitする？ / しすぎ vs しなさすぎ / 「とりあえず動いた」はOK？

→ commitの心理的ハードルを下げる

Section 2

コミットメッセージ

ダメな例 / 良い例 / テンプレート / 実践デモ

→ 未来の自分が読めるメッセージを書く

Section 3

あるあるミス

add忘れ / node_modules / mainで直接作業 / 間違えてcommit

→ よくある失敗と対処法を知る

Section 4

実践パターン

pushの恐怖 / チェックリスト / コマンドリファレンス

→ 自信を持ってGitを使えるようになる

いつコミットすればいい？

初心者の悩み

"全部終わってからcommit?" — "1行変えただけでcommit?" — "いつが正解？"

答え:「意味のある単位」でcommit

ダメな例

git commit -m "色々変更"
# 500行変更、3機能追加、バグ2つ修正
# → あとで何がいつ変わったか不明

良い例

git commit -m "feat: ログインフォーム追加"
git commit -m "fix: バリデーションエラー修正"
git commit -m "style: ヘッダーのCSS調整"
# → 1commit = 1つの目的

good commit pattern

コミットメッセージの書き方

こう書いてない？

"update"
"fix"
"修正"
"あああ"
"test"
"WIP"
"asdf"
# 3ヶ月後の自分「何これ...」

こう書こう

"feat: ログインフォームのバリデーションを追加"
"fix: メール送信時のnullエラーを修正"
"docs: READMEにセットアップ手順を追加"
"style: ボタンのhoverアニメーションを調整"
"refactor: ユーザー認証ロジックを分離"
# 未来の自分への手紙

テンプレート: <type>: <何を><なぜ>

feat fix docs style refactor test chore

コミットメッセージ実践デモ

悪い例 vs 良い例を git log で見比べてみよう

commit message comparison

変更してないのにcommitしたい

初心者あるある

"commitできない...壊れた？" → いいえ、変更がないだけです

Gitは「差分」を記録するツール。変更がなければ記録する必要がない。

nothing to commit

git add を忘れる

初心者あるある No.1

ファイルを編集 → git commit → "nothing to commit" → 「あれ？」

ファイル編集

→

git commit
忘れた!

ファイル編集

→

git add

→

git commit

git add demo

コミットしすぎ vs しなさすぎ

しすぎ

        "add space"

        "remove space"

        "add space again"

        "typo"

        "fix typo"

        "fix typo again"

        "oops"

履歴がノイズだらけ。意味のある変更が埋もれる。

ちょうどいい

        "feat: ユーザー登録画面を作成"

        "feat: バリデーション追加"

        "fix: メール形式チェック修正"

        "style: フォームのレイアウト調整"

        "test: 登録フォームのテスト追加"

1commit = 1つの意味ある変更。履歴がきれい。

しなさすぎ

        "1週間分の作業"

        変更ファイル: 47個

        追加: 2,340行

        削除: 890行

        何がいつ変わった？

問題が起きてもどこで壊れたか特定できない。

目安: "このcommitで何をした？"を一文で説明できるならちょうどいい粒度

間違えてcommitした！

慌てなくて大丈夫。状況に応じた対処法がある。

パターン1

メッセージを間違えた

        git commit --amend

        -m "正しいメッセージ"

pushしてない場合のみ!

パターン2

余計なファイルをcommit

        git reset HEAD~1
      

直前のcommitを取り消し。ファイルは残る。やり直せる。

パターン3

もうpushしちゃった

        git revert HEAD
      

「打ち消しcommit」を作る。履歴を書き換えず安全。

undo commits

「とりあえず動いた」はcommitしていい？

YES!

むしろcommitすべき

❌

"完璧なコード"を待つ

→ 永遠にcommitできない
→ 途中で壊しても戻れない
→ 全部失う可能性がある

✅

こまめにcommit

→ いつでも戻れるセーブポイント
→ 後からきれいにできる
→ 安心して実験できる

commitは「保存」。ゲームのセーブと同じ。

WIP (Work In Progress) commitを活用しよう:
git commit -m "WIP: ログイン機能を実装中"

後から git commit --amend できれいなメッセージに書き換えればOK

.gitignoreを忘れてnode_modulesをcommit

パニック案件

git add . → 1万ファイルがステージングされる → 「え？？」

.gitignore rescue

教訓: プロジェクト開始時に.gitignoreを最初に作る

mainブランチで直接作業しちゃった

初心者の心の声

"ブランチ？面倒だからmainでいいや" → あとで困る

branch rescue

ブランチを切るタイミング:

新しい機能 バグ修正 実験・試行錯誤

pushが怖い

初心者の恐怖

"pushしたら戻せない？" "壊したらどうしよう？" "チームに迷惑をかける？"

現実

✔pushしても git revert で戻せる ✔ブランチを使えばmainは壊れない ✔PR(プルリクエスト)でレビューしてからマージすればOK ✔個人リポジトリなら何をしても大丈夫

心理的ハードルを下げるコツ

🧪

練習用リポジトリを
作って実験する

🌿

ブランチで作業
mainは安全

🤝

PRでレビュー
一人じゃない

💪

失敗は学び
怖がらなくて大丈夫

初学者あるあるチェックリスト

これを覚えておけば怖くない！

.gitignoreをプロジェクト開始時に作る
commitは「意味のある単位」で
メッセージは未来の自分への手紙
add を忘れずに（edit → add → commit）
迷ったらとりあえずcommit（後から直せる）
pushを恐れない（revertで戻せる）
練習用リポジトリを作って実験する

大丈夫、みんな最初はこうだった。
失敗しながら覚えていこう！

Appendix: コマンドリファレンス

この編で登場したコマンドまとめ

git status現在の状態を確認（変更ファイル、ステージング状況） git add <file>ファイルをステージングエリアに追加 git commit -m "msg"ステージングされた変更をコミット git commit --amend -m "msg"直前のコミットメッセージを修正（push前のみ） git reset HEAD~1直前のコミットを取り消し（ファイルは残る） git revert HEAD直前のコミットを打ち消す新しいコミットを作成 git stash作業中の変更を一時的に退避 git stash pop退避した変更を復元 git checkout -b <branch>新しいブランチを作成して切り替え git rm --cached <file>Gitの追跡から外す（ファイル自体は残る） git log --onelineコミット履歴を1行ずつ表示 git diffまだステージングしていない変更を表示