[提案]ブランチルールの制定

[y-chan]

※このIssueは本旨のReDoSとは無関係であるため、優先度は低め

より効率的かつ円滑な開発のため、git-flowベースのブランチルール(ブランチモデル)の制定を提案します。

What is Branch Rule?

ブランチを切る際のルールです。主に、どういう規則でブランチを切るのか、どこにマージするものなのかを決めます。これにより、どういう目的のブランチなのかを把握し、開発をより円滑に行えるようにします。

ブランチルール草案

• メインブランチ: master
  • メインのブランチです。ここに機能する最新のコードがある前提です。
• 開発ブランチ: develop
  • 開発ブランチです。ここをメインに開発し、masterからブランチを切り、問題なくコードが動くようであればmasterにマージします。
• 機能追加ブランチ: feature/{ISSUE_NUMBER}-**
  • なにか新しい機能を実装するときや、リファクタをかけるときにこのブランチネーミングを使います。
  • 基本的にまずは実装する機能についてIssueで提示します(めんどくさいかもしれませんが、これをすることでそのfeatureブランチがどんな機能追加のコードが書かれているのかを把握しやすくするため) -ブランチのチェックアウト元・マージ先はdevelopか、feature/のみとします。
• 問題・バグ修正用ブランチ: fix/{ISSUE_NUMBER}-** or fix/**
  • 何かしら実装のバグや問題があった時、このブランチネーミングを使い、ブランチを切ります。
  • feature/と同じく、まずIssueを立てることを推奨します。(絶対とは言いません。PRで言及されればよいです)
  • ブランチのチェックアウト元・マージ先はdevelopか、feature/のみとします。
• 緊急のバグ修正等用ブランチ: hotfix/{ISSUE_NUMBER}-** or hotfix/**
  • masterブランチにおいてバグや問題が確認されてしまった場合、緊急の修正が必要になります。その際にこのブランチネーミングを用います。
  • fix/と同じく、まずIssueを立てることを推奨します。(絶対とは言いません。PRで言及されればよいです)
  • ブランチのチェックアウト元・マージ先はmasterのみとします。また、同じ内容のPRをdevelop向けにfix/で作ることを推奨します。

これらを完成させ次第(ブラッシュアップが必要そう)、最終的にCONTRIBUTING.mdにまとめます。