[研究] Githubによるプロジェクト進行・タスク管理


# 概要

一般的には、ソースコード管理・共同開発ツールとしてGithubは使われますが、
プロジェクト進行・タスク(チケット) 管理ツールとしても、Githubは非常に有効です。
Githubを使うことによって、研究のPDCAサイクルを行うことができます。

この記事では、ソースコードの管理のためではなく、Issueを使いこなすツールとしてGithubを紹介します。昨今の研究スピードでは、タスク管理による取捨選択はMustなはずです。

メリットについて説明したのち、Githubの実際の使い方を示します。



# メリット


- プロジェクトを遂行する仕事をIssueという単位のチケットで管理することによって、 タスクの小分け・具体化がされるので、`日々のタスクがわかる`。
- Project機能によって、タスクの進捗を可視化できるので、個々の作業の進み具合を共有できるので`作業が重複しない`。
- 開発のログ・思考プロセスが１つのツールに残せるので、`共有、引継ぎ` にかかる作業が少ない。

Issueそのものについては[こちらの書籍](https://www.amazon.co.jp/s/ref=nb_sb_ss_i_3_5?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&url=search-alias%3Daps&field-keywords=issue%E3%81%8B%E3%82%89%E3%81%AF%E3%81%98%E3%82%81%E3%82%88&sprefix=Issue%2Caps%2C254&crid=38NR1JJ89J337)が非常に参考になります。

# 使い方
## 初期設定

まずはリポジトリを作ります。リポジトリの作り方はその辺にドキュメントがあるでしょう。


## 研究のPDCAサイクル

PDCAサイクルの順で説明します。

## Plan: 計画
## 1. Issueをつくる。
  何はともあれ Issueを作ります。Issueは直訳すると課題, IssuesはTO-DOリストみたいなものです。
  プロジェクトに今ある課題を全部Issueとして作りましょう。
  
  1. Issues タブからNew Issueを選択
  2. Title にはわかりやすい端的な名前。Descriptionには課題の内容、WhatとWhyを書きます。
    他のレポジトリのIssueの書き方を参考にしたらいいと思います。
![](https://d2mxuefqeaa7sj.cloudfront.net/s_AF076CC4B1446265980231245633BC41752DAA9B340B32FE255176CB3C4E8221_1551321982482_Screen+Shot+2019-02-28+at+11.41.10.png)

- **Issue に強弱をつける。**

  IssueにLabelsをつけて、研究の必須度、タスクの種類に分けるのもいいですし、
  Milestonesをつけて、Issueの期日を設定するのもよいです。
## 2. プロジェクト機能を活用する
  Issueを作ったら、次はどのIssueから取り組んでいくかを決めます。


  1. ProjectsタブからCreate new projectを選択。
  2. 適当なTitleをつける.
  3. テンプレートは個人作業ならAutomated Kanban, 複数人で開発するなら(コードレビューを行ったりする)なら Automated Kanban with reviews を選択すれば丸いです。
  4. 最初は何もないので、右のAdd cardsよりIssueをとってきてTo doに追加します。
    ([自動でカード追加するトリガーというものも設定できる](https://qiita.com/matsubara0507/items/f384991b4854aa28745a)みたいです.)
  1. 取り組むIssueが決まったら、そのIssueをIn progressに移動します。
    これでPlanは完了しました。


![](https://d2mxuefqeaa7sj.cloudfront.net/s_AF076CC4B1446265980231245633BC41752DAA9B340B32FE255176CB3C4E8221_1551323780263_image.png)

## Do: 開発する。
  Issueに取り組みます。
  
  Issueがプログロム開発に関係していて, Githubの本来の機能(ソースコード管理)を使う場合の具体的なコマンドは他を参考にしてください。ここでは概略だけ。
  
  1.  IssueのIDを確認する (IssueのIDをユニークに決定されます)
![](https://d2mxuefqeaa7sj.cloudfront.net/s_AF076CC4B1446265980231245633BC41752DAA9B340B32FE255176CB3C4E8221_1551324709776_Screen+Shot+2019-02-28+at+12.30.40.png)
![](https://d2mxuefqeaa7sj.cloudfront.net/s_AF076CC4B1446265980231245633BC41752DAA9B340B32FE255176CB3C4E8221_1551324613848_Screen+Shot+2019-02-28+at+12.28.36.png)

  
  2. 作業ブランチの名前に`IssueのID`をつける. ユニークなIDを使って, branchを作ります。
    > git checkout -b #12_test
  3. 開発する。
  これでDoは完了します。


## Check: 確認・レビューする。
  Issueの内容に沿ったことができたか、振り返って確認します。
  
  ここでもプログラムに関わるところは、概略のみ示します。
1. オリジンの作業ブランチにプッシュ
> git add .
> git commit -m “add/implementation_hogehoge”
> git push origin #12_test
> // githubリモートの#12_test というブランチにpush. 


2. オリジンの作業ブランチをMasterブランチにマージ
  1. Create pull request
    pull requestの内容は実験ノートを書くのもいいですし、共同開発できるならちゃんとフォーマットにのって書いたほうがいいですね。何も書かないのもありですかね。
  
- **レビューをお願いする**
- 
  ReviewersにGithubのUserを設定して、レビューしてくれる人を設定します。レビュワーから認可してもらえないと、Merge Pull Requestが送れないはずです。
  AssigneesはPull Requestの責任者？担当者ってイメージです。
![](https://d2mxuefqeaa7sj.cloudfront.net/s_AF076CC4B1446265980231245633BC41752DAA9B340B32FE255176CB3C4E8221_1551325727780_image.png)
![](https://d2mxuefqeaa7sj.cloudfront.net/s_AF076CC4B1446265980231245633BC41752DAA9B340B32FE255176CB3C4E8221_1551325994966_image.png)

  b. Merge Pull Request
  レビュワーの認可が終わったり、Masterブランチとのコンフリクトがなければ無事にMerge pull requestができるはずです。
![](https://d2mxuefqeaa7sj.cloudfront.net/s_AF076CC4B1446265980231245633BC41752DAA9B340B32FE255176CB3C4E8221_1551326138910_image.png)

  これでCheckは終わりです。
## Action: 再計画。
  とりあえず ProjectのIssuesを In Progressから、Doneに移動させましょう。
  また、Checkの内容を踏まえて、新しいIssueを作ったり、Issueの優先度を見直したりしてください。


**追記**

- Slackを導入している研究室なら、SlackにGithubのアプリを導入することによって通知がSlackにいくようになります。ちょっとした議論等はその辺でやることが多いです。