gitflow について
開発チーム向けに Gitflow のブランチモデルを説明するスキルです。ブランチの役割と命名、Conventional Commits、プルリクエストのルール、セマンティックバージョニング、リリースとホットフィックスの手順を扱います。
主な機能
- 01長期・補助ブランチの役割
- 02ブランチ命名規則
- 03Conventional Commits 形式
- 04プルリクエストとブランチ保護のルール
- 05リリースとホットフィックスの手順
活用シーン
- 01develop を起点にした機能開発
- 02main 向けリリースブランチの準備
- 03hotfix ブランチによる緊急修正の公開
- 04コミットメッセージとバージョン更新の標準化
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/gitflowを入力して読み込まれたか確認します。
詳細
Gitflow
このスキルでは、Gitflow のブランチモデルについて説明します。長期間維持する 2 つのブランチ、3 種類のサポートブランチ、コミットメッセージの規約、セマンティックバージョニング、リリースとホットフィックスの手順を取り上げます。
機能変更のワークフロー
- develop を同期する —
git checkout develop && git pull origin developを実行して、最新の開発状態から機能ブランチを作成できるようにします。 - 機能ブランチを作成する —
git checkout -b feature/123-user-authenticationを実行し、命名規則feature/[issue-id]-descriptive-nameに従います。 - 規約に沿ったメッセージでコミットする — すべてのコミットに
type(scope): descriptionを使用します（下記の「コミットメッセージ」を参照）。 - develop をリベースまたはマージする — PR を作成する前に、ブランチを最新の状態にします。
git fetch origin && git rebase origin/developを実行します（またはチームの規約に従ってマージします）。 - develop 宛てにプルリクエストを作成する — 少なくとも 1 件の承認と CI チェックの合格を必須にします。
developに直接コミットしてはいけません。 - マージして後片付けする — マージ後、ローカルとリモートの両方で機能ブランチを削除します。
git branch -d feature/123-user-authentication && git push origin --delete feature/123-user-authentication。
メインブランチ
main（または master）
- 本番環境に対応できるコードのみを含みます。
mainに直接コミットしてはいけません。hotfix/*ブランチまたはrelease/*ブランチからのマージのみを受け入れます。- マージのたびに、バージョン番号でタグ付けする必要があります（例：
git tag -a v1.2.0 -m "Release 1.2.0"）。
develop
- メインの統合ブランチです。最新の開発成果を含みます。
- すべての
feature/*ブランチの作成元です。 developに直接コミットしてはいけません。すべての変更はプルリクエストを通じて取り込みます。
サポートブランチ
feature/*
- 作成元：
develop。 - マージ先：
develop。 - 命名規則：
feature/[issue-id]-descriptive-name（例：feature/123-user-authentication）。 - PR を作成する前に、
developの最新状態に更新する必要があります。 - マージ後に削除します。
release/*
- 作成元：
develop。 - マージ先：
mainおよびdevelop。 - 命名規則：
release/vX.Y.Z（例：release/v1.2.0）。 - 対象はバグ修正、ドキュメント、リリース関連の作業に限ります。新機能は含めません。
- マージ後に削除します。
hotfix/*
- 作成元：
main。 - マージ先：
mainおよびdevelop。 - 命名規則：
hotfix/vX.Y.Z（例：hotfix/v1.2.1）。 - 本番環境の緊急修正専用です。
- マージ後に削除します。
コミットメッセージ
Conventional Commits 形式 type(scope): description を使用します。
| Type | 意味 |
|---|---|
feat | 新機能 |
fix | バグ修正 |
docs | ドキュメントの変更 |
style | 書式の変更、セミコロンの不足など。ロジックの変更はありません |
refactor | 動作を変えずにコードを再構成 |
test | テストの追加または修正 |
chore | メンテナンス作業（ビルドスクリプト、依存関係の更新など） |
例：
feat(auth): add refresh-token rotation
fix(orders): prevent duplicate charge on retry
chore(deps): bump lodash to 4.17.21
セマンティックバージョニング
バージョン MAJOR.MINOR.PATCH の場合：
- MAJOR — 互換性のない変更や破壊的変更を API に加えた場合に増加します。
- MINOR — 後方互換性のある新機能を追加した場合に増加します。
- PATCH — 後方互換性のあるバグ修正を行った場合に増加します。
プルリクエストのルール
- すべての変更はプルリクエストを通じて行う必要があります。
mainやdevelopへの例外はありません。 - マージ前に、少なくとも 1 件の承認が必要です。
- すべての CI チェックに合格する必要があります。
- 保護されたブランチ（
main、develop）への直接コミットは禁止です。 - マージ前に、ブランチをマージ先の最新状態に更新する必要があります。
- マージ後にブランチを削除します（ローカルとリモートの両方のコピー）。
ブランチ保護ルール
main と develop の両方に適用します。
- マージ前にプルリクエストのレビューを必須にします。
- マージ前にステータスチェックの合格を必須にします。
- マージ前にブランチを最新の状態に更新することを必須にします。
- 管理者も制限の対象に含めます（昇格された権限によるルールの回避を禁止）。
- 強制プッシュを禁止します。
- ブランチの削除を禁止します。
リリースプロセス
developからリリースブランチを作成します：git checkout -b release/v1.2.0 develop。- パッケージマニフェスト／変更履歴のバージョン番号を更新します。
- リリース固有の問題（ドキュメント、直前のバグなど）を修正します。新機能は追加しないでください。
- リリースブランチから
mainへの PR を作成します。 mainへのマージ後：- リリースにタグを付けます：
git tag -a v1.2.0 -m "Release 1.2.0"を実行し、タグをプッシュします。 mainをdevelopにマージし、リリースコミットとタグがdevelopに含まれるようにします。- リリースブランチを削除します。
- リリースにタグを付けます：
ホットフィックスプロセス
mainからホットフィックスブランチを作成します：git checkout -b hotfix/v1.2.1 main。- 本番環境の問題を、可能な限り小さな変更で修正します。
- パッチバージョンを更新します。
- ホットフィックスブランチから
mainへの PR を作成します。 mainへのマージ後：- リリースにタグを付けます：
git tag -a v1.2.1 -m "Hotfix 1.2.1"を実行し、タグをプッシュします。 - 修正が次のリリースで失われないよう、
mainをdevelopにマージします。 - ホットフィックスブランチを削除します。
- リリースにタグを付けます：
コメント
Markdown 対応