結論：ブランチ＝作業の「分岐」、マージ＝分岐の「合流」です。つまずきの大半は、コマンドが難しいからではなく「今どのブランチにいて、HEADが何を指しているか」を見失うことと、コンフリクト表示の読み方を知らないことの2つに集約されます。 どちらも、実際に自分でブランチを切って合流させ、わざとコンフリクトを起こして直す、という体験を1回すれば一気にほどけます。
なお、git add・commit・push といった基礎からの人は、先に Git使い方入門（add・commit・push） を読んでからここに戻ってくると理解が早いです。この記事は「基礎の次＝ブランチとマージ専門」で、初心者が実際に詰まる場所だけを掘り下げます。用語としての Git と GitHub の違いが曖昧なら GitとGitHubの違い もどうぞ。
ブランチとは ― 「作業の分岐」であって、コピーではない
多くの入門記事は「ブランチ＝作業のコピー」と説明しますが、これがつまずきの元になります。ブランチの正体は、**あるコミットを指す軽い「付箋（ポインタ）」**です。ファイルを丸ごと複製しているわけではありません。
mainもfeatureも、それぞれ「どのコミットが枝の先端か」を指しているだけ。- あなたが今いる場所を指す特別な付箋が HEAD です。「HEAD が
featureを指している」＝「今featureブランチで作業している」という意味。 - 新しくコミットすると、今いるブランチの付箋（と HEAD）だけが1つ前に進みます。
この「付箋が動くだけ」というイメージを持つと、後のマージも rebase も「付箋をどう動かすか」の話として一直線に理解できます。まずは git branch ― 枝を作る と git switch ― 枝を移動する をブラウザでそのまま実行して、ブランチを作って移動する感覚を掴んでください（無料・登録不要・環境構築なし）。実際に手を動かせるので、git switch の前後で HEAD がどう移るかが目で見えます。
「今どのブランチにいるか」を見失わないコツ
初心者のトラブルは、たいてい「間違ったブランチで作業していた」に行き着きます。防ぐ習慣はシンプルです。
- 何かする前に必ず
git status。今のブランチ名と、変更・ステージの状態が一度に分かります。3つのエリア（作業ツリー / ステージ / コミット済み）の関係は git status ― 3つのエリアを理解する で手を動かすと腹落ちします。 - ブランチを切り替える前に、手元の変更をコミットしておく（または退避しておく）。
- ブランチ上で普通にコミットを積んでいく流れは ブランチで作業する で体験できます。
「今どこにいるか」を口癖のように確認するだけで、この後のマージ事故はほぼ防げます。
マージ ― 合流には2種類ある（fast-forward と マージコミット）
マージは「取り込む先に移動してから、取り込みたいブランチ名を指定する」操作です。ここで初心者が「あれ？」となるのが、マージの結果が状況によって2通りある点です。
- Fast-forward（早送り）：取り込む先（例：
main）が、枝分かれしてから一切コミットしていない場合。Git は付箋を前にスライドさせるだけで済み、Fast-forwardと表示されます。新しいマージコミットは作られません。 - マージコミット：
main側もfeature側も両方が進んでいた場合。合流点に「2つの親を持つコミット」が新しく作られます。
「マージしたのにコミットが増えた／増えなかった」で混乱するのは、この2種類を知らないからです。まずは git merge ― 枝を合流させる をブラウザで実行して、Fast-forward と表示される素直なケースを体験してください。付箋が前に進むだけ、という感覚が掴めます。
つまずきの本丸 ― コンフリクトの「読み方」
初心者が最も身構えるのがコンフリクト（衝突）です。でも仕組みは単純で、2つのブランチが同じファイルの同じ場所を別々に書き換えたとき、Git が「どちらを採用すべきか自動で決められない」だけです。エラーでも故障でもありません。Git はマージを止めて、衝突箇所をファイルの中にマーカー付きで残してくれます。
<<<<<<< HEAD (main)
main の説明
=======
feature の説明
>>>>>>> feature読み方はこうです。
<<<<<<<から=======までが 自分（今いる側＝HEAD） の変更。=======から>>>>>>>までが 相手（取り込もうとしたブランチ） の変更。
やることは3つだけ。(1)「正しい最終形」に自分で書き直す、(2) マーカー3行（<<<・===・>>>）を消す、(3) git add で「解決済み」と伝えて git commit。どちらか一方を残すのも、両方を活かして書き直すのも自由です。
このプロセスは、読むだけだと必ず不安が残ります。わざとコンフリクトを起こして自分の手で直す、を1回やるのが最短の克服法です。マージコンフリクト ― 衝突を解決する はまさにその手順を、ブラウザ上のシミュレートGitで安全に体験できるレッスンです（本物のリポジトリを壊す心配なし・無料）。一度通せば「怖いもの」ではなくなります。
merge と rebase の違い ― どちらを使うべきか
「merge と rebase、どっちを使えばいいの？」も定番の疑問です。結論から言うと、両方とも「別々に進んだ枝を1つにする」目的は同じで、履歴の残り方が違うだけです。
- merge：合流点にマージコミットを残す。「いつ・何を合流したか」がそのまま履歴に残る。分岐したという事実を保存したいときに向く。
- rebase：自分のブランチのコミットを、相手ブランチの先端に積み直して一直線にする。マージコミットを作らず、履歴が枝分かれのないきれいな1本になる。
使い分けの目安はこうです。
- 手元だけの・まだ push していないブランチを整える → rebase で履歴を一直線にすると読みやすい。
- すでに共有している履歴 → merge が安全。
ここに超重要な落とし穴があります。rebase の黄金律：すでに push して他人と共有しているコミットは rebase してはいけません。 rebase はコミットを作り直す（＝中身が同じでも別物に置き換える）ため、共有済みの履歴を積み直すと、チーム全員の履歴と食い違って大混乱します。「まだ自分しか触っていない枝を整えるときに使う」と覚えてください。
rebase は言葉だけだと「コミットを付け替える」がイメージしにくいので、図と実行で確かめるのが一番です。git rebase ― 履歴を一直線に積み直す をブラウザで実行すると、枝分かれした履歴が git rebase main の一発で一直線につながる様子を、自分の手で再現できます。
rebase 中にコンフリクトが出たら
rebase はコミットを1つずつ積み直すため、その途中でコンフリクトが起きることがあります。慌てる必要はありません。merge のときと読み方も直し方もまったく同じ（マーカーを読んで書き直し → git add）で、違うのは最後に git commit ではなく「続きを進める」操作を使う点だけです。この一連の流れは rebase のコンフリクトを解決する で手を動かして確認できます。
つまずいたら、まず手を動かす
ブランチ・マージ・コンフリクト・rebase は、文章を何度読んでも「わかった気」で止まりがちな分野です。理由は単純で、HEAD や付箋が「動く」ものだから、静止した文章では動きが見えないからです。だからこそ、実際にコマンドを打って付箋が動くのを見るのが一番効きます。
Become-Coder の Gitコース は、ブラウザ上で動くシミュレートGitを使うので、環境構築なし・無料・登録不要で、ブランチ作成 → マージ → コンフリクト解決 → rebase までを実際に手を動かして体験できます（第1〜3章はすべてブラウザ内で実行できます）。ローカルに Git をインストールする前の「予行演習」にも最適です。
次に読む・手を動かす
- git branch ― 枝を作る（ブラウザ実行）
- git switch ― 枝を移動する（ブラウザ実行）
- ブランチで作業する（ブラウザ実行）
- git merge ― 枝を合流させる（ブラウザ実行・Fast-forward を体験）
- マージコンフリクト ― 衝突を解決する（ブラウザ実行・つまずきの本丸）
- git rebase ― 履歴を一直線に積み直す（ブラウザ実行）
- rebase のコンフリクトを解決する（ブラウザ実行）
- 基礎から：Git使い方入門（add・commit・push）
- 用語整理：GitとGitHubの違い