- コミットメッセージの書き方
- [Pull Request の書き方](##Pull Request の書き方)
- Issue の書き方
- コミットログが見やすいこと
- チーム開発の理解の助けになること
- なぜそのようなコードを書いているかわかること
- レビューがしやすいこと
- コミットメッセージは個人の作業ログではなく、製品の変更履歴であるべき
[Prefix]: [Subject]
[Body]
[Issue ID]
プレフィックスの種別についてはAngularJSの開発ルールを参照
| 種別 | 用途 |
|---|---|
| feat | 機能開発 |
| fix | バグ修正 |
| docs | ドキュメントの変更。README など |
| style | 機能に影響のないコードの整形（スペース、インデント、セミコロン等 |
| refactor | 機能の変更のないコードの修正 |
| perf | パフォーマンスを改善するコードの修正 |
| test | テストコード関連 |
| chore | 製品に関係のないビルドタスクやジェネレートツール関連 |
何を変更したのかを短い文章に。 変更内容を端的に表せると Good
- feat: TOP ページ作成
- fix: コンテキストメニューの表示座標のズレを修正
- chore: 画像の圧縮タスクを追加
なぜ変更したのかを文章に。
- 変更が必要だった理由
- どうしてそのように変更したのか（修正方針
- どのように（コードの実装や動作）は重要ではない
- タイトルで完結してしまったら書かなくて良い
⭕️GOOD
fix: コンテキストメニューの表示座標のズレを修正
表示する親要素に包含ブロックを指定していなかったため、モーダル内ではズレが発生したので、テーブルコンポーネントを包含ブロックに修正
❌BAD
fix: コンテキストメニューの表示座標のズレを修正
position: relative;を指定
関連する Issue ID があれば記載
fix: コンテキストメニューの表示座標のズレを修正
表示する親要素に包含ブロックを指定していなかったため、モーダル内ではズレが発生したので、テーブルコンポーネントを包含ブロックに修正
Issue #48
- 目的が不明
- 何をレビューして良いのかわからない
- 差分が大きい
- 単純に見るのが大変
- 複数の目的の変更が入っている
- 確認が大変なのと、指摘が広い反映に及ぶと閉じるのが遅くなる
- ケアレスミスの指摘が多い
- プルリクエスト本来のビューまでたどり着くのが困難
レビューしづらいことで
- レビューの精度が下がる
- プルリクエストを閉じるのが遅くなり、機能実装が完了しない
- 他の変更が取り込まれてコンフリクトの解消に追われる
- そのプルリクエスト起点の機能開発ができなる
- レビュワーの開発時間が失われる
などのデメリットが発生し、開発工程の遅れ・クオリティの低下などに繋がる
レビュワーのことを思い、レビューしやすい丁寧なプルリクエストを作成することを心がける
- 小さくプルリクする
- 早くプルリクする
- レビュワーと共通認識が形成できていること
- コンフリクトはプルリクを出している人が直す
不確実性・難易度の高いタスクほど小さく早くトライ&エラーとフィードバックで解消していくこと
まず、プルリクエストを作成してから作業を開始すること。
本リポジトリの .github/pull_request_template.md を利用して、自動でプルリクエスト本文のテンプレートを作成することをおすすめする。
Work In Progress(WIP) のプルリクエストを作成し、
- タイトル
- チケット番号
- 「やったこと」にやる予定の作業
- 「やらないこと」にプルリクエストの責務ではない作業
を入力する。
そのため、プルリクエストの目的や作業内容を明確にしてから作業を行える！
開発時に想定していない改修が発生した場合はプルリクエストを分割することを考慮すること。
ex) ビルドタスクの改修や別 JS class に手を入れる時
空のコミットの作り方
git commit --allow-empty -m "Initial commit"