GitHubを中心とした開発プロセス 課題管理

GitHubを中心とした開発プロセスの課題管理編です

[milestone] Issueの対応期限を明示する

適切な対応期限を設定して積み残さない様にしよう

使い方

ここからMilestoneの作成・編集が出来るぞ

開始日と終了日とタイトル、任意で説明を記述する

作ったMilestoneはLabelやAssigneesと同じようにIssueやPullRequestに設定できる

Milestoneの一覧画面では、関連するものの数や、進捗を見ることが出来る

Label等と同様にIssue一覧画面ではMilestoneでのフィルタリングも出来るので、Issue等の優先度を理解しやすくなるぞ

[issue link, pull request link] IssueやPullRequestを紐付ける

関連するIssueやPullRequestは紐づけておこう

どうして？

• Issueで議論をして、対応するPullRequestが作られるという流れが多いから
• 紐づいたもののステータスや作成者もわかるので、漏れが起きにくい
• 自動で相互リンクになるため、派生Issue等が作られても束ねやすく辿りやすい

PullRequestを作る時にIssueを紐づけるとリンクになる

自動で相互リンクになり、このIssueに関連するPullRequestがOpenしていることがわかる

やり方

1. #1の様に、#に続けて番号を書くだけ

番号はIssueやPullRequestのページ等で確認出来る

[fixes commit] PullRequestのマージ時にIssueを自動的にクローズする

Issueはわざわざ自分でCloseしないでマージ時に勝手にCloseさせよう

方法

1. コミット時にfixes #1やclosed #1とメッセージに含める
2. PullRequestのマージ時に対象Issueが自動でCloseする

PullRequestをCloseした直後だが、自動でCloseされている

どう役に立つ？

• IssueのCloseし忘れは珍しくないが、この方法はとても楽にCloseすることが出来る
• 後述予定のZenHubにおいても効果を発揮する

[git template for issue] Issue作成時の説明欄にテンプレートを設定する

テンプレートを使って明瞭で完了させやすいIssueを書こう

使い方

1. ISSUE_TEMPLATE.md、もしくは.github/ISSUE_TEMPLATE.mdというMarkdownを用意する
2. Issueを作成する

たとえば以下の様なファイルを用意した場合

## 目的

## TaskList
+ [ ] 

## Doneの定義

## 参考

## 留意事項
+ 

## 検討事項
+ 

Issue作成ボタンを押した時には既に上記のMarkdownが記述されている（下画像はプレビュー中）

良い点

• 絶対に外せない項目は「目的」と「Doneの定義」
  • 要は「なぜそのIssueが存在し」て「何を達成したら問題が解決する」のかを必ず明示させる
• 具体的に行うことを列挙するためのTaskListも大切
• Doneの定義が明確になることで、Issueが適切な粒度になる
• テンプレート自身もGitで管理出来る

Issueってつい「submit時のJSを直す」とか「参照ロジックを直す」みたいなことだけ書いて作っちゃうけど、
対応するのが自分じゃあ無かったり時間が経ってたりすると「なんだっけ？」ってなりがちだと思う

それを防ぐためにも、例えばこんな感じに書く事を強く推奨するよ

残念な点

• タイトルは対象外
• 複数のテンプレートを使い分けることはできない
• 必ずテンプレートが挿入される

[git template for pull request] PullRequest作成時の説明欄にテンプレートを設定する

PullRequestもテンプレートを用いて適切なレビューを受けよう

使い方

1. PULL_REQUEST_TEMPLATE.md、もしくは.github/PULL_REQUEST_TEMPLATE.mdというMarkdownを用意する
2. PullRequestを作成する

たとえば以下の様なファイルを用意した場合

## 目的

## 関連するIssue等
+ 

## レビューポイント
+ 

## 留意事項
+ 

## 残課題
+ 

PullRequest作成ボタンを押した時には既に上記のMarkdownが記述されている（下画像はプレビュー中）

良い点

• Issueのテンプレートと同じように、絶対に外せない点は「目的」
  • 目的があると自然とレビュー内容や関連課題に意識が行くので、適切なレビューを受けやすい
• 仕事の内容によっては例えば「動作確認済みブラウザ」なんて項目があっても良いと思う
• 関連Issueは#1 〜〜の形式で書くと先述の通り相互連携されるので書くと良い
• 対応IssueのDoneの定義がPullRequestマージの場合は、fixes #1とCommitすれば後でIssueが勝手にCloseする
• Commitを重ねる間に別問題に気付いた様な場合、残課題に書いている
  • 別対応となる場合は、新たにIssueを作り#2 〜〜の様に書くと、後に参照しやすい

残念な点

• こちらも同様に、タイトルは対象外で、複数のテンプレートを使い分けることは出来ない

Issue/PullRequestのテンプレートを使って

• 存在は知っていたけど、ここまで良いとは思わなかった
• 「目的」「レビューポイント」「Doneの定義」があるだけで、明瞭なIssueを作成でき、適切にレビューを受けて、安心してDoneさせることが出来ると実感した
• 作成時に勝手に出てくるけど邪魔なのであえて消した、という様な困ったことは意外となかった
• お手軽な割にとても良い効果が得られるので、すごいおすすめ

[saved replies] レビューコメントのテンプレートを設定する

よく使うコメントのフレーズはあらかじめ登録しておこう

使い方

この画面でフレーズを登録することが出来る

コメント入力時に矢印アイコンを押すと登録済みのフレーズが選択出来る

疑問点

最近出来た機能だと思うのだけれど、リポジトリ単位の設定ではなくて個人設定であることが少ししっくりこない
多分OSSリポジトリでの「コメントありがとう！けどすぐ回答出来ないので調査して返答するよ！」みたいなレンプレ回答に使うのかな、って思った

うまく使えば便利そうではあるので、おまけ的な感じで紹介してみたよ

[search box] リポジトリ内の何かを検索する

検索機能を使いこなして素早く目的の何かを見つけよう

実は色々細かい検索が出来る

下のはたまに使う程度だけど、知ってると地味に便利

この記事が色々書いてあって良いと思う

GitHub Issueの検索でできること - Qiita

よろしければ他記事もどうぞ

• もくじ
• ドキュメント管理
• 公開
• 自動化
• ZenHub
• 満足していないこと