GitHubの運用について
- 自分の担当するプロジェクトで設定していたコーディングルール
- 備忘録として書いておこうと思う
ブランチ運用ルール
- GitHubは下記ブランチを使い分けてソース運用(管理)する
main：本番環境用
- stagingブランチからのみプルリクエストを作成する
staging：ステージング環境(営業確認(テスト)用)
- devブランチからのみプルリクエストを作成する
dev：開発環境
- 基本の開発環境。本ブランチからのみfeature/***ブランチを作成する
feature/NEWBRANCH：作業用ブランチ
- 作業時に、dev環境から作業用ブランチを切り出して実装する
- 同様のチケットで複数作業をする場合は
feature/NEWBRANCH-nのように後ろに数字をつける - ※ただし、基本的に同じチケットで複数作業をするのではなく、チケットを別途作成できるようにタスクの粒度を調整する
- 同様のチケットで複数作業をする場合は
ローカル開発環境
作業イメージ
dev ┬----> feature/NEWBRANCH-XXX ---> dev ---> staging ---> main
└----> feature/NEWBRANCH-YYY ------^
コミットの粒度及びプルリクエストの取り扱いについて
コミットメッセージ
- 各コミットには、コミットのカテゴリごとに下記のプレフィックスを付与することとする
- 例)「 feat: 〇〇機能を追加 」など
| プレフィックス | 該当の編集 |
|---|---|
| feat | 新機能の追加・新規編集・（他に該当しない場合は基本的にこのプレフィックス） |
| fix | 不具合の修正 |
| docs | ドキュメントのみの変更 |
| style | コードの処理に影響しない変更(スペースとか、書式設定とか、セミコロンの欠落とかの修正) |
| refactor | バグ修正や機能の追加を行わないコードの変更 |
| perf | パフォーマンス改善を行うためのコードの変更 |
| test | テストの項目抜けや、既存のテストの修正を行う |
| chore | ドキュメントの生成や、ビルドプロセス、ライブラリとツールをなどの変更 新機能の追加 |
| design | cssなどのスタイルだけの修正 |
| delete | 不要ファイルの削除のみ実施 |
コミットのタイミング(粒度)
- できるだけメソッド単位や同じ処理のひとまとまりを意識すること
- 例えば、DB接続のための処理を作成したら、DB接続のための処理だけをひとまとまりとして)「feat: 〇〇モデルへの接続処理追加」として、コミットするなど
- また、条件を追加した時に、「feat: ●●するための条件を追加」というようにコミットしていく
プルリクエストのタイミング(粒度)
- タスク単位で作成すること
- 最小の機能単位でレビューに出すこと(タスクも最小単位で作成すること)
- 「一覧ページ表示機能の追加」「登録機能の追加」のように、CRUD周りの機能も各機能ごとに切り出して実施すること
例：新規CRUD機能の実装
- 下記のような粒度となるイメージ
- 登録部分を実装したプルリク
- 削除部分を実装したプルリク
- 更新部分を実装したプルリク
- 一覧画面を実装したプルリク
- 削除機能を実装したプルリク
プルリクエストの名称
- 原則、「一目で何の対応をしたのかがわかる」ようにする
- 例：ユーザーの新規登録機能実装
プルリクエストのマージ
- プルリクエストはレビュアーに対してレビュー依頼を出すこと
- マージは、レビュアーが行うこと
- マージされたブランチは削除すること（dev, stagingを削除しないように注意）
staging及びmainへのマージタイミング
- タスクが完了し、レビューが完了した時点でマージを行う
- mainへの反映は本番へのリリースとなるため、基本的にリリース以外でマージすることはない
テスト実施
- テストは開発環境(dev)ブランチにて実施する
- コードレビュー → dev環境へマージ → テスト実施というフローになる