はじめに
Gitは強力なバージョン管理ツールですが、使い方を間違えると大変なことになります。
この記事では、実務で使えるブランチ戦略から、よくある失敗とそのリカバリ方法まで、完全網羅します。
対象読者：
- Gitの基本は分かるが、実務での使い方に不安がある方
- ブランチ戦略を学びたい方
- 失敗したときの対処法を知りたい方
- チーム開発でGitを使う予定の方
この記事で分かること：
- main/develop/feature/* の使い分け
- 日常的な操作フロー
- 失敗したときのリカバリ方法
- 便利なコマンド集
ブランチ戦略の基本
なぜブランチを分けるのか
1つのブランチだけだと：
main
├─ 機能Aを開発中
├─ 機能Bを開発中
└─ バグ修正中
→ すべてが混ざって混乱ブランチを分けると：
main（本番）
├─ develop（開発）
│ ├─ feature/機能A
│ ├─ feature/機能B
│ └─ fix/バグ修正
└─ hotfix/緊急修正それぞれ独立して作業できる！
Git Flow：最も一般的なブランチ戦略
main（本番環境）
├─ 常に安定版
└─ リリース済みのコード
develop（開発環境）
├─ 開発中のコード
└─ すべての作業の起点
feature/*（機能開発）
├─ feature/login
├─ feature/payment
└─ 開発完了後、developにマージ
hotfix/*（緊急修正）
├─ hotfix/critical-bug
└─ 本番の緊急バグ修正各ブランチの役割
mainブランチ
役割：
- 本番環境のコード
- 常に動作する状態
- リリース済みの確定版
ルール：
- ❌ 直接編集しない
- ✅ developまたはhotfixからマージのみ
- ✅ タグでバージョン管理
例：
main
├─ v1.0.0
├─ v1.1.0
└─ v2.0.0developブランチ
役割：
- 開発環境のコード
- すべての機能開発の起点
- 次のリリース候補
ルール：
- ✅ feature/* からマージを受け入れる
- ✅ テスト済みの機能のみマージ
- ✅ mainより先に進んでいる
イメージ：
develop = main + 開発中の機能feature/* ブランチ
役割：
- 個別の機能開発
- 独立して作業できる
- 開発完了後、developにマージ
命名規則：
feature/ログイン機能
feature/決済機能
feature/ユーザー管理ライフサイクル：
1. developから作成
2. 機能開発
3. developにマージ
4. ブランチ削除hotfix/* ブランチ
役割：
- 本番の緊急バグ修正
- mainから直接作成
- mainとdevelopの両方にマージ
使用タイミング：
本番でバグ発見
↓ 緊急修正が必要
hotfix/critical-bug を作成
↓ 修正
mainにマージ（本番反映）
↓ 同時に
developにもマージ（開発環境にも反映）基本操作
ブランチの作成と切り替え
新しいブランチを作成して切り替え
git checkout develop
git checkout -b feature/new-function
# または
git switch -c feature/new-function説明：
-bオプションで作成と切り替えを同時に実行switchは新しいGitコマンド（v2.23以降）
既存のブランチに切り替え
# developに切り替え
git checkout develop
# mainに切り替え
git checkout mainブランチ一覧を確認
# ローカルブランチ一覧
git branch
# 出力例：
main
* develop ← *が現在のブランチ
feature/login
# リモートブランチも含めて表示
git branch -a
# 出力例：
* develop
main
remotes/origin/develop
remotes/origin/main
remotes/origin/feature/loginコミット
ステージングとコミット
# ファイルをステージング
git add file.txt
# すべてのファイルをステージング
git add .
# コミット
git commit -m "feat: ログイン機能を追加"コミットメッセージの規約
Conventional Commits:
:
type:
- feat: 新機能
- fix: バグ修正
- docs: ドキュメント
- style: コードスタイル
- refactor: リファクタリング
- test: テスト
- chore: その他 例：
git commit -m "feat: ユーザー登録機能を追加"
git commit -m "fix: ログインエラーを修正"
git commit -m "docs: READMEを更新"プッシュ
リモートにプッシュ
# 現在のブランチをリモートにプッシュ
git push origin feature/login
# 初回プッシュ時（追跡ブランチを設定）
git push -u origin feature/login
# 次回以降
git push-u オプション：
- upstream（追跡ブランチ）を設定
- 次回以降は
git pushだけでOK
マージ
developにマージ
# developに切り替え
git checkout develop
# featureブランチをマージ
git merge feature/login
# 出力例：
Updating abc1234..def5678
Fast-forward
login.js | 50 +++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
# リモートにプッシュ
git push origin developmainにマージ
# mainに切り替え
git checkout main
# developをマージ
git merge develop
# プッシュ
git push origin main日常的な運用フロー
パターン1：新機能を開発
Step 1：featureブランチを作成
# developから作成
git checkout develop
git pull origin develop # 最新の状態に更新
# featureブランチ作成
git checkout -b feature/user-profileStep 2：開発作業
# ファイルを編集
code user-profile.js
# コミット（何度でも）
git add user-profile.js
git commit -m "feat: ユーザープロフィール表示機能"
git add user-profile.css
git commit -m "style: プロフィール画面のスタイル調整"
git add tests/user-profile.test.js
git commit -m "test: ユーザープロフィールのテスト追加"Step 3：リモートにプッシュ
# 初回
git push -u origin feature/user-profile
# 2回目以降
git pushStep 4：developにマージ
# developに切り替え
git checkout develop
# 最新の状態に更新
git pull origin develop
# featureブランチをマージ
git merge feature/user-profile
# コンフリクトがなければ
git push origin develop
# featureブランチを削除（オプション）
git branch -d feature/user-profile
git push origin --delete feature/user-profileパターン2：複数の機能を並行開発
# 機能A開発
git checkout develop
git checkout -b feature/function-a
# 開発...
git push origin feature/function-a
# 機能Bも開発したい
git checkout develop # developに戻る
git checkout -b feature/function-b
# 開発...
git push origin feature/function-b
# 機能Aに戻る
git checkout feature/function-a
# 開発続き...ポイント：
- 各機能が独立して開発できる
- いつでもブランチを切り替えられる
パターン3：mainへのリリース
# developの作業が完了
git checkout main
git pull origin main
# developをマージ
git merge develop
# タグを付ける
git tag -a v1.0.0 -m "バージョン1.0.0リリース"
# プッシュ
git push origin main
git push origin v1.0.0よくある失敗とリカバリ
失敗1：mainで誤って作業してしまった
状況
# mainブランチにいることに気づかず作業
git add file.txt
git commit -m "機能追加"
# あっ、mainだった！
git branch
# * main ← まずい！リカバリ方法A：まだプッシュしていない場合
# コミットを取り消し（変更は残る）
git reset --soft HEAD~1
# developに切り替え
git checkout develop
# 再度コミット
git add file.txt
git commit -m "機能追加"
git push origin developreset --soft：
- コミットだけ取り消し
- ファイルの変更は残る
- ステージング状態も残る
リカバリ方法B：すでにプッシュしてしまった場合
# developに該当のコミットを持っていく
git checkout develop
git cherry-pick コミットハッシュ
git push origin develop
# mainから削除
git checkout main
git revert コミットハッシュ
git push origin maincherry-pick：
- 特定のコミットだけを別ブランチに適用
revert：
- コミットを打ち消す新しいコミットを作成
- 履歴は残る（安全）
失敗2：developとmainがずれてしまった
状況
main: 最新の状態
develop: 古い状態
→ mainで作業してしまった
→ developに反映されていないリカバリ方法：mainの変更をdevelopにマージ
# developに切り替え
git checkout develop
# mainの変更を取り込む
git merge main
# 出力例：
Updating abc1234..def5678
Fast-forward
file.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
# プッシュ
git push origin developこれで同期完了！
失敗3：コミットメッセージを間違えた
まだプッシュしていない場合
# 最後のコミットメッセージを修正
git commit --amend -m "正しいメッセージ"すでにプッシュしてしまった場合
# 修正
git commit --amend -m "正しいメッセージ"
# 強制プッシュ（注意！）
git push -f origin feature/my-branch⚠️ 注意：
git push -fは履歴を書き換える- チーム開発では使わない（他の人の作業が壊れる）
- 自分専用のブランチでのみ使用
失敗4：間違ったファイルをコミットしてしまった
まだプッシュしていない場合
# 最後のコミットを取り消し（変更は残る）
git reset --soft HEAD~1
# 正しいファイルだけをステージング
git add correct-file.txt
git commit -m "メッセージ"
# 間違ったファイルは破棄
git checkout -- wrong-file.txtすでにプッシュしてしまった場合
# ファイルを削除するコミット
git rm wrong-file.txt
git commit -m "不要なファイルを削除"
git push origin feature/my-branch失敗5：コンフリクトが発生した
状況
git merge feature/function-a
# 出力：
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.解決手順
1. コンフリクトしているファイルを確認：
git status
# 出力：
Unmerged paths:
both modified: file.txt2. ファイルを開いて編集：
<<<<<<< HEAD
現在のブランチの内容
=======
マージしようとしているブランチの内容
>>>>>>> feature/function-aどちらを採用するか決める：
# 最終的な内容（コンフリクトマーカーを削除）
採用する内容3. コミット：
git add file.txt
git commit -m "merge: コンフリクトを解決"便利なコマンド
空コミット
ファイルを変更せずにコミット：
git commit --allow-empty -m "chore: CI/CDをトリガー"使用例：
- CI/CDを再実行したい
- Git履歴に記録を残したい
- ファイル変更なしでプッシュしたい
特定のコミットを別ブランチに適用
# コミットハッシュを確認
git log --oneline
# 出力例：
abc1234 feat: 機能追加
def5678 fix: バグ修正
# 別ブランチに切り替え
git checkout target-branch
# 特定のコミットを適用
git cherry-pick abc1234コミット履歴を確認
# 簡易表示
git log --oneline
# グラフ表示
git log --graph --oneline --all
# 出力例：
* abc1234 (HEAD -> develop) feat: 機能追加
* def5678 (origin/develop) fix: バグ修正
* ghi9012 (main) chore: 初期設定変更内容を確認
# まだステージングしていない変更
git diff
# ステージング済みの変更
git diff --staged
# ブランチ間の差分
git diff develop..main変更を一時保存
# 変更を一時保存
git stash
# 別のブランチで作業...
# 変更を復元
git stash pop
# stash一覧
git stash list使用例：
- 作業中に別のブランチに切り替える必要がある
- コミットしたくないが、変更を保存したい
ブランチを削除
# ローカルブランチを削除
git branch -d feature/old-feature
# まだマージしていないブランチを強制削除
git branch -D feature/old-feature
# リモートブランチを削除
git push origin --delete feature/old-featureGitHub連携
Re-run jobs（GitHub Actions）
GitHub Actions が失敗したときの再実行方法：
方法1：GitHub UIから再実行（推奨）
GitHub → Actions
→ 失敗したWorkflow
→ Re-run jobs
→ Re-run all jobsメリット：
- コード変更不要
- 設定変更後に使う
方法2：空コミット
git commit --allow-empty -m "chore: GitHub Actions再実行"
git push origin mainメリット：
- Git履歴に記録される
- コマンドラインで完結
Pull Request（PR）
チーム開発での標準フロー：
Step 1：featureブランチで開発
git checkout -b feature/new-function
# 開発...
git push origin feature/new-functionStep 2：GitHub でPRを作成
GitHub → Pull requests
→ New pull request
→ base: develop ← compare: feature/new-function
→ Create pull requestStep 3：レビュー
チームメンバーがレビュー
→ コメント
→ 承認Step 4：マージ
Merge pull request
→ Confirm merge
→ Delete branch（オプション）ベストプラクティス
1. 作業前に必ずブランチ確認
# 習慣化する
git branchまたは、プロンプトに表示：
# ~/.bashrc に追加
parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}
export PS1="\[\033[32m\]\w\[\033[33m\]\$(parse_git_branch)\[\033[00m\] $ "表示例：
~/project (develop) $2. 小まめにコミット
# 悪い例
git add .
git commit -m "いろいろ修正"
# 良い例
git add login.js
git commit -m "feat: ログイン機能追加"
git add login.css
git commit -m "style: ログイン画面のスタイル調整"
git add tests/login.test.js
git commit -m "test: ログイン機能のテスト追加"メリット：
- 履歴が分かりやすい
- 問題があったときに特定しやすい
- レビューしやすい
3. 定期的にdevelopを更新
# 作業開始時
git checkout develop
git pull origin develop
# mainの変更も取り込む
git merge origin/main
# featureブランチでも定期的に
git checkout feature/my-feature
git merge develop # developの最新を取り込むメリット：
- コンフリクトを早期に発見
- 最新の状態で開発できる
4. 意味のあるコミットメッセージ
# 悪い例
git commit -m "修正"
git commit -m "update"
git commit -m "fix"
# 良い例
git commit -m "feat: ユーザー登録機能を追加"
git commit -m "fix: ログインエラーを修正（#123）"
git commit -m "docs: READMEに環境構築手順を追加"5. mainとdevelopを保護
GitHub設定：
Settings → Branches
→ Add branch protection rule
main:
✅ Require pull request reviews
✅ Require status checks to pass
❌ Allow force pushes
develop:
✅ Require pull request reviews
❌ Allow force pushesこれで：
- 誤って直接プッシュできない
- レビューが必須
- 安全性向上
チートシート
ブランチ操作
# ブランチ一覧
git branch
# ブランチ作成
git checkout -b feature/new
# ブランチ切り替え
git checkout develop
# ブランチ削除
git branch -d feature/oldコミット操作
# コミット
git add .
git commit -m "メッセージ"
# コミット修正
git commit --amend -m "修正後のメッセージ"
# コミット取り消し（変更は残る）
git reset --soft HEAD~1
# 空コミット
git commit --allow-empty -m "メッセージ"リモート操作
# プッシュ
git push origin branch-name
# プル
git pull origin branch-name
# リモートブランチ削除
git push origin --delete branch-nameマージ操作
# マージ
git merge branch-name
# コンフリクト確認
git status
# マージ中止
git merge --abort確認系
# 状態確認
git status
# 履歴確認
git log --oneline
# 差分確認
git diff
# ブランチ確認
git branch -aリカバリ系
# 変更を破棄
git checkout -- file.txt
# コミット取り消し
git reset --soft HEAD~1
# コミット打ち消し
git revert コミットハッシュ
# 特定のコミットを適用
git cherry-pick コミットハッシュまとめ
ブランチ戦略
main（本番）
↓ マージ
develop（開発）
↓ マージ
feature/*（機能開発）ルール：
- mainで直接作業しない
- developですべての開発
- featureで個別機能
基本フロー
1. featureブランチ作成
2. 開発・コミット
3. developにマージ
4. mainにマージ（リリース時）失敗時の対処
mainで誤って作業
→ developにマージ
コミットミス
→ reset --soft
コンフリクト
→ 手動で解決覚えておくべきコマンド
git branch # ブランチ確認
git checkout -b # ブランチ作成
git merge # マージ
git reset --soft # コミット取り消し
git stash # 一時保存おわりに
Gitは最初は難しく感じるかもしれません。
でも、基本的な流れを理解して、失敗を恐れずに使っていけば、必ず使いこなせるようになります。
この記事が、あなたのGit習得の助けになれば幸いです。
Happy Coding! 🚀
参考リンク
最終更新： 2026-01-12
コメント