gitルール

[makoto00000]

git運用ルール

team dragonのgit運用ルールを以下のように定めます。

１．ブランチ

ブランチ名	説明
main	直接の作業は行わない、実際に稼働しているサービスと同等のコードを管理するブランチ。
develop	開発用のベースとなるブランチ。mainから派生させる。
feature	作業用、機能開発用ブランチ。developから派生させる。実装完了後はdevelopへマージ。
fix	バグ修正用ブランチ。修正完了後はdevelopへマージ。

運用方法

• developブランチから、featureまたはfixブランチを派生。
• プルリクエストを作成して、developブランチへマージ。
• リリースできる段階になったら、developブランチをmainブランチへマージ。

ブランチ名について

基本は下記２つで運用して、難しい場合は適宜考える。

・feature（新機能開発）

feature/{issue番号}_{内容}

例：feature/#8_add_menu

・fix（バグ修正）

fix/{issue番号}_{内容}

例：fix/#21_fix_bug

２．コミット

Format

${prefix}: {やったこととその理由}

例: 「 fix:ユーザー情報にnameが足りないのでnameを追加 」

長文になる場合は本文に詳細を書く。

Prefix 一覧

• add（新規機能・ファイル追加）
• fix（バグの修正）
• refactor（リファクタリング）
• update（バグではない機能の改善、バージョンアップ等）
• rename（ファイル名の変更）
• remove（ファイルの削除）
• move（ファイルの移動）

３．プルリクエスト

• レビュー依頼前に今一度開発ルール、コーディング規約を確認する。
• ひとつのプルリクエストが膨大にならないよう、差分が大きくなりそうな場合はキリのいいところで区切ってプルリクエストを出す。
• 1日1プルリクエストになるようにタスクを細分化する。
• 内容はプルリクエストテンプレートに従う。
• Reviewerは自分以外の3人が行う。ApproveまたはRequest changesを選択。
• 全員からApproveが得られれば、プルリクエスト作成者がマージを行う。

４．タスク管理

Issuesを使って行う。

タスクの進め方

• Asigneesに自分を選択。
• ステータスをIn Progressに変更。
• 実装が終わったらプルリクエストを作成。
• レビューが終わったらマージしてクローズ。

Label一覧

Label	意味
📝 docs	ドキュメントのみ。
🌟 feature	機能を追加する。featureブランチを作成する。
🐛 bug	バグが発生している。fixブランチを作成して対応する。
♻️ refactor	動いてはいるが、リファクタリングした方が良い。
🚫 invalid	対応するのが困難なIssueにつけてクローズする。

Label	内容
🏎️ 優先度：高	絶対に対応する
🛵 優先度：中	できれば対応した方が良い
🚲 優先度：低	対応しなくても良い

タスクの作成

• 原則、機能単位、バグ単位でIssueを作成する。
• 細かいタスクがある場合は、issue内にtodoリストを作成する。

５．その他ルール

• 1時間以上悩むようならメンバーに相談する

[makoto00000]

プルリクエスト テンプレート

実施タスク

例：issue #2

実施内容

• 例：ヘッダーの作成を行いました。
• 例：メインコンテンツの余白を調整しました。

レビューしてほしいこと

• 例：デザイン通りに表示されること
• 例：PC・SP サイズで表示崩れがないこと
• 例：リンクの確認

備考

• 例：ハンバーガーメニュー開閉時のアニメーションについては、別 PR で実装します。