Skip to content

Latest commit

 

History

History
71 lines (49 loc) · 3.32 KB

File metadata and controls

71 lines (49 loc) · 3.32 KB

Git 管理

1. 概要

Git 管理における運用ルールやベストプラクティス

2. ブランチ戦略

ブランチ マージ元 マージ先 説明 名前例
main develop --------- 本番環境用コード、リリースの安定版 main
develop feature main 開発用メインブランチ、リリース準備 develop
feature/<feature-name> develop develop 新機能開発用ブランチ feature/user-authentication
release/<version> --------- main, develop リリース準備、バージョン管理 release/1.0.0
hotfix/<bug-fix> main main 本番環境での緊急バグ修正 hotfix/critical-bug

2.1 マージのルール

  • develop -> main: リリース準備が整った段階で、developからmainにマージします。リリースバージョンに関しては、releaseブランチを使って調整します。
  • feature -> develop: 個別の機能開発が完了したら、featureブランチをdevelopにマージします。
  • hotfix -> main: 本番環境で発生した緊急のバグ修正が必要な場合、mainに直接マージします。修正後、developにもその内容を反映させます。

2.2 バージョン管理

リリース準備が整った段階で、release/<version>ブランチを作成します。このブランチでは、リリース候補のバージョンの調整や最終的なバグ修正を行い、mainおよびdevelopにマージしてリリースを完了させます。

3. コミットメッセージのルール

3.1 プレフィックス

コミットメッセージには以下のプレフィックスを使用します。プレフィックスは変更内容の種類を一目でわかりやすくするために重要です。

  • [Feature]: 新機能の追加
  • [Fix]: バグ修正
  • [Docs]: ドキュメントの修正
  • [Refactor]: コードのリファクタリング
  • [Test]: テストの追加
  • [Chore]: ビルドや依存関係の更新、その他雑務

3.2 例

コミットメッセージは明確で簡潔に記述します。以下に例を示します。

[Feature] 新機能の実装

- ログイン機能の追加
- JWTによる認証を実装
[Fix] バグ修正

- ユーザーのプロフィール更新時にエラーが発生する問題を修正
[Docs] ドキュメントの修正

- API のエンドポイント仕様書を更新