「とりあえず push して」の恐怖
入社して最初のタスクを終え、先輩に言われました。
「じゃあそれ、GitHubにプッシュしといて」
当時の私はGitを「なんかバージョン管理するツール」としか理解していません。とりあえず覚えたてのコマンドを打ちました。
$ git add .
$ git commit -m "修正"
$ git push origin main
数分後、Slackに先輩から怒涛のメッセージが。
「おい！mainに直接pushしたぞ！！CI壊れてる！！」
何がいけなかったのか、何も分かりませんでした。
Gitを「セーブ機能」で理解する
Gitは複雑で難しそうに見えますが、ゲームの「セーブ機能」に例えると一気に腹落ちします。
git add ＝ セーブしたいファイルを選ぶ
$ git add index.html style.css
# 「この2ファイルをセーブ対象にする」
git commit ＝ セーブする（ローカルに記録する）
$ git commit -m "ヘッダーのデザインを修正"
# 「"ヘッダーのデザインを修正"という名前でセーブ」
git push ＝ セーブデータをクラウドにアップロードする
$ git push origin feature/header-fix
# 「feature/header-fix というセーブスロットにアップロード」
なぜ main ブランチに直接 push してはいけないのか
main ブランチは、「本番環境に反映される神聖なセーブデータ」です。
ここに直接変更を入れるということは、ゲームで言えば「配布用のマスターROMに直接書き込む」ようなもの。バグが入ったら全プレイヤー（＝全ユーザー）に影響します。
正しい流れはこうです。
1. main から「作業用のコピー（ブランチ）」を作る
$ git checkout -b feature/header-fix
2. そのブランチで作業してコミットする
$ git add . && git commit -m "ヘッダー修正"
3. ブランチをpushして、プルリクエスト（PR）を作る
$ git push origin feature/header-fix
→ GitHub上でPRを作成
4. 先輩にレビューしてもらい、OKが出たらmainにマージ
main ──────────●─────────────────●──── (安全に守られている)
\ /
feature/header ●──●──●──●──● ← ここで自由に作業
新人が覚えるべきGitコマンド（これだけでOK）
# ブランチを作って移動する
$ git checkout -b feature/作業名
# 変更をステージングしてコミットする
$ git add .
$ git commit -m "何をしたかを書く"
# リモートにpush（mainではなく自分のブランチ）
$ git push origin feature/作業名
# mainの最新を自分のブランチに取り込む
$ git pull origin main
# やらかした時のお守り（直前のコミットを取り消す）
$ git reset --soft HEAD~1
コミットメッセージの書き方
❌ "修正"
❌ "fix"
❌ "あああ"
❌ "わからん"
✅ "ログイン画面のバリデーションエラーメッセージを修正"
✅ "ユーザー一覧APIのページネーションを追加"
✅ "READMEにセットアップ手順を追記"
コミットメッセージは**「未来の自分（と先輩）への手紙」**です。3ヶ月後に git log を見た時、「このコミットで何をしたか」が一目で分かるように書きましょう。
Gitは最初は怖いですが、「セーブ＆ブランチ」の概念さえ掴めば、コードを壊す恐怖から永久に解放されます。大丈夫、git reset と git reflog がある限り、Gitで本当にデータが消えることはほぼありません。怖がらずに、まず checkout -b でブランチを切ることから始めてください。