GitHubでIssueを書くときに気をつけることとかいろいろ
タイトルだけでIssueの内容が把握できるようにする。
Issueがバグの場合は、設計要素の名称を書く。
【xx画面】xxボタン押下時にエラー など...
Issueがバグの場合、以下の内容を簡潔に書く。
複数の問題をひとつのIssueに含めない。面倒だけど問題の数だけIssueを発行する。
OSやブラウザのバージョンなど
Windows 7 、Chrome 44
できる限り詳しく再現の手順を書く。
- xx画面を表示する
- xx項目にユーザ名を入力する
- xxボタンを押下すると「～～～」というエラーが表示される
どうなるのが正しい動作を書く。
わかれば修正の仕方も書く。
バグ報告をするときに使う。
→ 修正したらクローズする
過去に報告されているIssueと重複しているときに使う。
※ 報告者は使わない
→ 重複先のIssueにリンクしてクローズする
機能追加の要望や改善してほしいときに使う。
→ 実装したらクローズする
Issueの内容が間違いであるときに使う。仕様通り。
※ 報告者は使わない
→ 対処しない理由を書いてクローズする
質問したいときに使う。
→ 質問・議論の答えがでたらクローズする
認知しているけど対処しないバグのときに使う。
※ 報告者は使わない
→ 対処しない理由を書いてクローズする
マイルストーンを指定することで、「いつまでに何をやらなければならないのか」が集計される。
タスク管理や進捗管理として使われる。
Issueを誰に割り当てるかを指定する。
コミットメッセージに以下のフォーマットで記述すれば、自動的に該当Issue（#12）がCloseされる。
- fix #12
- fixes #12
- fixed #12
- close #12
- closes #12
- closed #12
- resolve #12
- resolves #12
- resolved #12
関連記事