慣例的ブランチ 1.0.0

要約

慣例的ブランチとは、Git ブランチの構造化された標準的な命名規則を指し、ブランチをより読みやすく実用的にすることを目的としています。使用したいブランチのプレフィックスをいくつか提案していますが、独自の命名規則を指定することもできます。一貫した命名規則により、タイプ別にブランチを識別しやすくなります。

重要なポイント

1. 目的主導のブランチ名: 各ブランチ名はその目的を明確に示し、すべての開発者がそのブランチの用途を理解しやすくします。
2. CI/CD との統合: 一貫したブランチ名を使用することで、自動化システム（継続的インテグレーション/継続的デプロイメントパイプラインなど）がブランチタイプに基づいて特定のアクションをトリガーするのに役立ちます（例：リリースブランチからの自動デプロイ）。
3. チーム連携: ブランチの目的を明確にすることでチーム内の連携を促進し、誤解を減らし、チームメンバーが混乱することなくタスク間を切り替えやすくします。

仕様

ブランチ命名のプレフィックス

ブランチ仕様は以下のプレフィックスをサポートし、次のような構造にする必要があります：

<type>/<description>

• main: メイン開発ブランチ（例：main、master）
• feature/（または feat/）: 新機能用（例：feature/add-login-page、feat/add-login-page）
• bugfix/（または fix/）: バグ修正用（例：bugfix/fix-header-bug、fix/header-bug）
• hotfix/: 緊急修正用（例：hotfix/security-patch）
• release/: リリース準備ブランチ用（例：release/v1.2.0）
• chore/: 依存関係やドキュメント更新などの非コードタスク用（例：chore/update-dependencies）

基本ルール

1. 小文字の英数字、ハイフン、ドットを使用: 常に小文字（a-z）、数字（0-9）、ハイフン（-）を使用して単語を区切ります。特殊文字、アンダースコア、スペースは避けてください。リリースブランチでは、バージョン番号を表すために説明部分でドット（.）を使用できます（例：release/v1.2.0）。
2. 連続、先頭、末尾のハイフンやドットは禁止: ハイフンとドットが連続して表示されないように（例：feature/new--login、release/v1.-2.0）、説明の先頭や末尾に表示されないようにしてください（例：feature/-new-login、release/v1.2.0.）。
3. 明確で簡潔に保つ: ブランチ名は説明的でありながら簡潔で、作業の目的を明確に示す必要があります。
4. チケット番号を含める: 該当する場合、プロジェクト管理ツールからのチケット番号を含めて追跡を容易にします。例えば、チケット issue-123 の場合、ブランチ名は feature/issue-123-new-login とすることができます。

結論

• 明確なコミュニケーション: ブランチ名だけで、そのコード変更の目的を明確に理解できます。
• 自動化フレンドリー: 自動化プロセスに簡単にフックできます（例：feature、release などの異なるワークフロー）。
• スケーラビリティ: 多くの開発者が同時に異なるタスクに取り組む大規模なチームでうまく機能します。

要約すると、慣例的ブランチは Git ワークフロー内のプロジェクト組織、コミュニケーション、自動化を改善するために設計されています。

よくある質問

なぜブランチの種類はConventional Commits（例：build、ci、docs、style、refactor）ほど詳細ではないのですか？

ブランチはコミットとは異なり、一時的なもので、主にマージされるまで使用されます。ブランチにあまり多くの種類を導入することは不要で、管理や記憶が難しくなります。

チームメンバーがこの仕様を満たしていない場合、自動的に識別するために使用できるツールは何ですか？

commit-check を使用してブランチ仕様をチェックするか、コードが GitHub でホストされている場合は commit-check-action を使用できます。