Loading...
メインコンテンツまでスキップ

branch 運用ルール

ブランチ運用フロー​

Git Flow(簡易版) は、開発ブランチを含む構造化されたブランチ運用戦略です。

dev ブランチでの統合とテストを経て、安定版を main ブランチにリリースします。

運用ルール​

メインブランチ（main）​

  • 本番環境用の安定版コードを管理
  • 直接コミットは禁止
  • 基本的に dev ブランチから merge
  • リリース準備が整った段階でのみ更新

開発ブランチ（dev）​

  • 開発用、ステージング環境用の統合ブランチ
  • feature ブランチのマージ先
  • ステージング環境にデプロイ
  • 新機能の統合とテストを実施

機能ブランチ（feature）​

  • 新機能開発用のブランチ
  • dev ブランチから分岐して作成
  • 作業完了後は dev にマージ
  • 機能単位で作成し、小さく短期間で完了させる

Pull Request​

  • feature → dev へのマージは必ず Pull Request を経由
  • dev → main へのマージも必ず Pull Request を経由
  • コードレビューを実施
  • テストの実行確認
  • 承認後にマージ

リリース・デプロイ​

  • dev → main へのマージ後、main のコードを利用して本番環境にデプロイ
  • dev ブランチは継続的にステージング環境にデプロイ可能

ブランチ命名規則​

テンプレート​

タイプ/#issue番号-{機能名}

// issueが無ければ以下
タイプ/{機能名}

タイプ一覧​

  • feature: 新しい機能の追加
  • bugfix: 既存の機能の不具合やエラー修正
  • hotfix: 本番環境での緊急性の高いエラー修正
  • docs: ドキュメント、README、コメント、ウェブサイトの文面や画像の変更
  • style: コードの書式設定（インデント、空白など）や構文上の修正
  • refactor: 仕様に影響がないコード改善(リファクタリング)
  • perf: 主にパフォーマンス向上を目的とした修正
  • test: テスト関連
  • chore: ビルド設定、依存関係の更新、ツール設定など、直接機能に影響しないメンテナンス作業

命名のポイント​

  • タイプが複数にまたがる場合は/区切りで複数入れる
  • 基本的に feature を利用する
  • feature merge 後の修正はbugfix, hotfixで行う
注記

コミットメッセージの方で詳細を記録するので、ブランチ単位ではこの Prefix は厳密につけなくてよいと思う

使用例​

feature/1-get-game-api

feature/get-game-api

bugfix/2-fix-login-error

hotfix/urgent-security-patch