# 1) 作業の基準点を最新化
git checkout main
git pull
# 2) 作業ブランチを作成して移動（branch + checkout を一発で）
git checkout -b feature/login
# 3) コード編集
git add .
git commit -m "コミットメッセージ"
# 4) main に戻って最新化（他人の更新が入る前提ならやる）
git checkout main
git pull
# 5) 作業ブランチを main にマージ
git merge feature/login
# 6) 作業ブランチを削除する（ローカルとリモート）
git branch -d refactor/structure
git push origin --delete refactor/structure
Code language: PHP (php)1. ブランチを切って作業する流れ
Git を使っていると、git checkout と git branch はかなり早い段階で登場します。
私がよく取る流れは、だいたい次のようなものです。
git checkout main
git pull
git checkout -b feature/loginここでやっていることを、感覚的に言い直すと、
- 今の基準点（main）を最新にする
- そこから別ルートを作る
- そのルートを「今の現実」にする
という順番です。
1.1. 作業の節目にマージする
ブランチは切るより、戻すときのほうが頭を使います。
git checkout main
git merge feature/loginこの操作は、
「別ルートでやってきた作業を、元の道に合流させる」
という感覚に近い。
コンフリクトが起きると、
「同時に 2 つの現実を整合させる作業」になります。
ここで初めて、ブランチが履歴であることを強く意識しました。
1.2. 失敗して破棄するとき
ブランチはまだコミットしていなければ、mainに戻って作業ブランチを削除するだけで消すことができます。
git checkout main
git branch -d feature/loginもし、リモートにコミットしている場合には、他の人からも見えなくするにはリモートからも消す必要があります。
git push origin --delete feature/login
Code language: JavaScript (javascript)ただし、マージ後に戻すのは大変です。
git revert <マージコミットのハッシュ>
Code language: HTML, XML (xml)マージ前の状態に戻す必要があります。
2. ブランチとは「作業の分岐点」
ブランチはよく「履歴の分岐」と説明されます。
それは事実ですが、実務感覚では少し抽象的に感じました。
私自身は、ブランチを
「今のコードの状態に名前を付けて、別の道を歩き始めること」
と捉えています。
一本道だった作業に、看板を立てて横道を作る。
そんなイメージです。
2.1. main を汚さない
main（あるいは master）は、多くの場合「動いている前提のコード」です。
ここを直接編集するのは、正直いつも少し怖い。
そこでブランチを切ります。
git branch feature/loginこの時点では、何も起きていません。
コードも、作業場所も変わっていない。
ただ「この地点に名前を付けた」だけです。
3. git checkout は「視点の切り替え」
git checkout は「ブランチを切り替えるコマンド」と説明されがちです。
もちろん間違いではありません。
ただ、私の中では
「Git に、どのブランチの世界を扱うか伝える操作」
という理解のほうがしっくり来ています。
git checkout feature/loginこの瞬間、作業ディレクトリの中身が切り替わります。
それまで存在しなかったファイルが現れたり、逆に消えたりします。
ここで初めて、「あ、別の世界に来たな」と実感します。
3.1. branch と checkout の役割分担
少し整理すると、こう捉えています。
git branch
名前を付けるだけ。場所は変わらない。git checkout
どのブランチの内容を作業対象にするかを切り替える。
最初はこの違いが曖昧でした。
ですが、意識して使い分けるようになると、操作の意味が見えやすくなりました。