「一人で開発してるから、Gitなんて必要ないかな？」「一人で開発してるから、ブランチ作るのなんて面倒」
全部！！！私の！！！セリフだ！！！
まぁそんな時代が私にもありました。
ですがGitのブランチ機能はチーム開発だけでなく、一人開発の効率と安全性を劇的に向上させる強力な武器になります。
この記事では、「なぜ一人開発でもブランチを使うべきなのか？」という理由から、具体的なコマンド操作、よくある開発シナリオでの活用例まで、ローカル環境でのGitブランチ活用法を頑張って書いてます。
一人開発でもGitブランチを使うべき3つのメリット
「どうせ自分しか使わないし…」と思うかもしれません。
しかし、gitを使うことで得られるメリットは非常に大きいのです。
理由1：安定版（main/masterブランチ）を常に動く状態に保てる(保護)
Gitの最大の特徴ともいえるブランチの作成。
最初に作成するブランチはmain(またはmaster）ブランチといいます。
mainブランチは、常に安定して動作するバージョンのコードを置いておく場所とするのが基本です。
作業中のコードや、まだ完成していない機能を直接mainブランチで開発してしまうと、「ちょっと試してみよう」と思った時に動かない、といった事態になりがちです。
Gitを使えば、mainブランチを常にクリーンな状態に保ちつつ、新しい作業は別のブランチで進めることができます。
理由2：機能追加やバグ修正を安全に分離・管理
開発作業は一つとは限りません。新しい機能を追加している最中に、別のアイデアを試したくなることも、既存コードの小さなバグに気づくこともあるでしょう。私はよくあります。
ブランチを切ることで、それぞれの作業を完全に独立した環境で行えます。
- 新機能開発ブランチ: 新しい機能のコードだけを追加・修正。
- バグ修正ブランチ: 特定のバグ修正に集中。
- 実験ブランチ: ちょっとしたアイデアを気軽に試す。
このように作業ごとにブランチを分ければ、互いの変更が影響し合う心配がなく、安心して開発に集中できます。もし実験が失敗しても、そのブランチを削除するだけで済み、mainブランチには何の影響もありません。
理由3：複数タスクの切り替えがストレスフリーに
「この機能開発、ちょっと時間がかかりそうだから、先にあの簡単なバグ修正を終わらせたいな…」
一人開発でも、作業の優先順位が変わることはよくあります。
ブランチを使っていれば、現在の作業をコミットしてブランチを切り替えるだけで、すぐに別の作業に移れます。修正が終わったら元のブランチに戻って作業を再開。中途半端な状態でファイルを退避させたり、コメントアウトしたりする必要はありません。この手軽さが、開発のスピードと快適さを大きく向上させます。
大まかなGitを使った開発の流れ
基本的にGitの開発は
- ブランチ操作
- コミット操作
- 開発ブランチをmainブランチにmergeする
の流れに沿って進みます。
①ブランチ操作
難しく考える必要はありません。まずは基本的なコマンドから覚えましょう。
基本的にはブランチを作成する・移動する・現在地を確認する・削除するの4つを使うことができれば大丈夫です！！
1. ブランチの作成と移動 (git switch -c)
新しい機能開発やバグ修正など、新しい作業を始めるときに使います。現在のブランチから分岐して、新しいブランチを作成し、そのブランチに移動します。
# "feature/new-login" という名前のブランチを作成し、そのブランチに移動する
git switch -c feature/new-login(補足: 以前は git checkout -b <ブランチ名> が使われていましたが、git switch -c の方が意図が明確でおすすめです。 git branch <ブランチ名> で作成だけ行うこともできますが、通常は作成と移動を同時に行います)
2. ブランチ間の移動 (git switch)
作業途中のブランチや、mainブランチなど、別のブランチに移りたいときに使います。
# "main" ブランチに移動する
git switch main
# 再び "feature/new-login" ブランチに戻る
git switch feature/new-login3. 現在のブランチを確認 (git branch)
現在いるブランチや、ローカルに存在するブランチの一覧を確認できます。*がついているものが現在のブランチです。
git branch
実行結果例：
main
* feature/new-login
bugfix/typo4. 役目を終えたブランチの削除 (git branch -d)
開発が完了し、mainブランチにマージされたブランチや、実験の結果不要になったブランチを削除します。リポジトリを綺麗に保つために重要です。
# mainブランチに移動してから削除するのが安全
git switch main
# "feature/new-login" ブランチを削除（マージ済みの場合のみ）
git branch -d feature/new-login
# マージされていないブランチを強制的に削除する場合 (注意!)
# git branch -D feature/experiment-failed(注意: -d はマージ済みのブランチしか削除できません。マージされていないブランチを強制削除する場合は -D を使いますが、作業内容が消えてしまうため慎重に使いましょう)
②コミット操作
開発ブランチで変更内容を記録するためには、「コミット」という操作が必要です。
コミットは以下の2ステップで行います
1. 変更したファイルをステージングエリアに追加 (git add):
# 開発ブランチでの作業が完了したら
# 特定のファイルを追加
git add ファイル名
# 変更したファイルをすべて追加
git add .2 . 変更をコミット (git commit)
# 変更内容を説明するメッセージと共にコミット
git commit -m "変更の説明文をここに書く"
コミットメッセージは何をしたか分かりやすいように書きましょう。③マージ操作
開発ブランチでの作業が完了したら、その成果を mainブランチに取り込みます。この操作を「マージ」と呼びます。
開発ブランチをmainブランチへマージする手順 (git addを含んで書いてます)
- 開発ブランチの作業が完了したら、変更をコミットしておく:
# 例えばfeature/new-login ブランチでの作業が完了したらの例git add .git commit -m "ログイン機能の実装完了" - 取り込み先のブランチ (
main) に移動する:git switch main - リモートリポジトリがある場合は最新の状態に更新する (念のため):
git pull origin main # ローカルのみの場合は上記のコマンドは不要 - 取り込みたいブランチ (
feature/new-login) を指定してマージを実行:git merge feature/new-login
これで feature/new-loginブランチでの変更内容がmainブランチに統合されました。
ローカルでのマージコンフリクト発生時の解決法
一人でローカルで開発している場合、git merge でコンフリクト（競合）が発生することは稀です。もし発生した場合は該当ファイルに
<<<<<<<, =======, >>>>>>>
といったマーカーを挿入して教えてくれます。
<<<<<<< HEAD
// main ブランチでの変更内容
=======
// feature/new-login ブランチでの変更内容
>>>>>>> feature/new-loginこれを解決するには以下のような手順をします。
- コンフリクトが発生したファイルをエディタで開きます。
- マーカー (
<<<<<<<,=======,>>>>>>>) を含む箇所を確認し、どちらの変更を採用するか、あるいは両方を組み合わせるかなど、手動でコードを修正します。 - マーカー箇所を全て修正し、ファイルを最終的な正しい状態にします。
- 修正したファイルを
git addします。git add <コンフリクトしたファイル名> - 最後に
git commitを実行してマージを完了させます。git commit-m “修正内容”
焦らず、一つずつ修正していけば大丈夫です。
まとめ：Gitでローカル開発をレベルアップ！
今回は、一人開発におけるGit活用法について解説しました。
- mainブランチは常に安定版を保つ
- 機能追加、バグ修正、実験は別ブランチで安全に行う
- 作業の切り替えが容易になり、開発がスムーズに
これらのメリットを享受するために、特別なことは必要ありません。git switch -c でブランチを作り、
作業が終わったら git switch main と git merge で統合し、git branch -d で掃除する。
この基本的な流れを覚えるだけで、あなたの開発体験は格段に向上するはずです。
最初は少し面倒に感じるかもしれませんが、慣れれば手放せなくなる便利な機能です。ぜひ今日から、あなたのローカル開発環境でもGitブランチを活用してみてください！
この記事がみなさんの一助となれば、いい感じにハッピーです。
