GitHub開発の基本！ブランチ運用からマージ、コンフリクト解決まで完全解説
GitHubを使った開発で「ブランチ」が必須な理由
複数人でひとつのソフトウェアやWebサイトを開発する際、GitHubは欠かせないプラットフォームとなっています。その中で最も重要な概念のひとつが「ブランチ（branch）」です。ブランチとは、履歴の流れを分岐して記録していく機能のことです。
本番環境で動いている安定したコード（通常はmainブランチ）に直接変更を加えると、バグが発生した際にシステム全体が止まってしまうリスクがあります。そこで、機能追加やバグ修正を行う際は、mainから自分専用の「ブランチ」を切り出して作業を行います。これにより、他の人の作業に影響を与えることなく安全に開発を進めることができ、最終的に完成したコードだけを合流（マージ）させることが可能になります。読者の皆さんがこの記事を最後まで読むことで、現場で通用するブランチ運用と、エラー時の対処法を身につけることができるでしょう。
目次
ブランチの基本操作と必須コマンド
それでは、実際の開発現場でよく使うコマンドの手順を見ていきましょう。ターミナル（コマンドプロンプトやMacのTerminalなど）を開いて操作します。
- 現在のブランチを確認する：
git branchを実行すると、ローカルにあるブランチの一覧が表示されます。現在いるブランチにはアスタリスクが付きます。 - 新しいブランチを作成して移動する：
git switch -c feature/add-loginのように実行します。これにより、「feature/add-login」という名前のブランチが作成され、同時にそのブランチへ切り替わります（旧来のgit checkout -bと同じ役割です）。 - 変更を記録する： ファイルを編集したら、
git add .で変更をステージングし、git commit -m "ログイン機能のUIを追加"でコミット（保存）します。 - GitHubにアップロードする：
git push origin feature/add-loginを実行し、ローカルで作成したブランチをリモート（GitHub）へプッシュします。
これらのコマンドは息をするように使えるようになるまで、何度も手元で練習することをおすすめします。
開発が完了したら「マージ」しよう
自分のブランチで機能の開発が完了し、テストも問題なく終わったら、いよいよその変更を大元のブランチ（mainなど）に合流させます。これを「マージ（merge）」と呼びます。
GitHubを利用したモダンな開発フローでは、コマンドラインから直接マージするのではなく、「Pull Request（プルリクエスト）」という機能を使います。プッシュが完了した後、GitHubの画面を開くと「Compare & pull request」というボタンが表示されています。これをクリックし、どのような変更を行ったのかタイトルや説明文を書いて送信します。チームの他のメンバーにコードをレビューしてもらい、承認が得られたら画面上の「Merge pull request」ボタンを押すことで、安全にmainブランチへマージされます。
コンフリクト（衝突）の発生原因と正しい解決手順
開発を進めていると、避けて通れないのが「コンフリクト（競合・衝突）」です。コンフリクトは、複数の人が同じファイルの同じ行を同時に編集し、それぞれがマージしようとした時に発生します。Gitが「どちらの変更を採用すべきか自動では判断できない」とギブアップした状態です。
コンフリクトが発生したからといって焦る必要はありません。以下の手順で確実に解決できます。
- コンフリクトの検知： マージを実行した際、「Automatic merge failed; fix conflicts and then commit the result.」というエラーメッセージが出ます。
- 状況の確認：
git statusを実行すると、「both modified」としてコンフリクトが起きているファイルが赤く表示されます。 - ファイルの修正： 該当ファイルをVS Codeなどのエディタで開きます。すると、
<<<<<<< HEADや=======、>>>>>>> branch-nameといった記号が挿入されています。これらは「あなたの変更」と「相手の変更」の境界線を示しています。 - 解決： どちらのコードを残すか、あるいは両方を組み合わせるかを人間が判断し、不要な記号（<<< など）を削除して正しいコードに整えます。
- 解決の記録： 修正が終わったら、再度
git add 該当ファイル名を行い、git commit -m "コンフリクトを解消"とコミットすれば完了です。
開発初心者が陥りやすい失敗例と落とし穴
ここで、Git/GitHubを使い始めたばかりの人がよくやってしまう失敗例を共有します。事前に知っておくことで、大きなトラブルを防ぐことができます。
- mainブランチで直接作業してしまう： ブランチを切り忘れてmainブランチで直接コードを書き、そのままコミットしてしまうケースです。気付いた時点で
git stashを使って変更を一時退避させ、新しいブランチを作成してからgit stash popで復元するといったリカバリーが必要です。 - リモートの最新状態を取り込まずに開発を始める： 古い状態のコードをもとに新しい機能を開発してしまうと、後で巨大なコンフリクトが発生する確率が高まります。作業を始める前には必ず
git pull origin mainなどで最新のコードを取り込む習慣をつけましょう。 - 意味不明なコミットメッセージ： 「修正」「あ」などの適当なメッセージをつけると、後からバグの原因を探る際に誰にも内容がわからなくなります。「なぜその変更をしたのか」が伝わる簡潔なメッセージを心がけましょう。
【保存版】コピペで使える！日常開発のGitコマンドフロー
毎日の開発業務でそのまま使える、標準的な一連のコマンドフローを用意しました。メモ帳などにコピーして活用してください。
- 1. メインブランチに移動：
git switch main - 2. 最新の情報を取得：
git pull origin main - 3. 作業用ブランチを作成：
git switch -c feature/ticket-123 - 4. （ここでコードをゴリゴリ書く）
- 5. 変更状態を確認：
git status - 6. 変更をステージに追加：
git add . - 7. コミットする：
git commit -m "〇〇の機能を追加" - 8. GitHubへプッシュ：
git push origin feature/ticket-123 - 9. GitHub上でPull Requestを作成し、マージする
よくある質問（FAQ）
Q. ブランチ名にはどのようなルールをつければ良いですか？
A. チームによりますが、一般的には「プレフィックス/内容」の形式が好まれます。新機能なら「feature/add-button」、バグ修正なら「bugfix/header-layout」のように、一目で目的がわかる名前をつけるのがベストプラクティスです。
Q. 間違えてコミットしてしまった場合、取り消せますか？
A. はい、まだプッシュしていないローカルのコミットであれば、git reset --soft HEAD^ を使うことで、ファイルの変更状態を残したままコミットだけを取り消すことができます。
Q. コンフリクトが怖くてマージできません。どうすれば慣れますか？
A. 最初は誰でも怖く感じるものです。個人用のテストリポジトリを作成し、意図的にコンフリクトを起こして解決する練習を数回行うと、仕組みが腑に落ちて恐怖感がなくなります。VS Codeなどのエディタに組み込まれているGitのGUIツールを使うと、視覚的に分かりやすくなるため非常におすすめです。