概要
一般的には、ソースコード管理・共同開発ツールとしてGithubは使われますが、
プロジェクト進行・タスク(チケット) 管理ツールとしても、Githubは非常に有効です。
Githubを使うことによって、研究のPDCAサイクルを行うことができます。
この記事では、ソースコードの管理のためではなく、Issueを使いこなすツールとしてGithubを紹介します。昨今の研究スピードでは、タスク管理による取捨選択はMustなはずです。
メリットについて説明したのち、Githubの実際の使い方を示します。
メリット
- プロジェクトを遂行する仕事をIssueという単位のチケットで管理することによって、 タスクの小分け・具体化がされるので、
日々のタスクがわかる。 - Project機能によって、タスクの進捗を可視化できるので、個々の作業の進み具合を共有できるので
作業が重複しない。 - 開発のログ・思考プロセスが１つのツールに残せるので、
共有、引継ぎにかかる作業が少ない。
Issueそのものについてはこちらの書籍が非常に参考になります。
使い方
初期設定
まずはリポジトリを作ります。リポジトリの作り方はその辺にドキュメントがあるでしょう。
研究のPDCAサイクル
PDCAサイクルの順で説明します。
Plan: 計画
1. Issueをつくる。
何はともあれ Issueを作ります。Issueは直訳すると課題, IssuesはTO-DOリストみたいなものです。
プロジェクトに今ある課題を全部Issueとして作りましょう。
- Issues タブからNew Issueを選択
- Title にはわかりやすい端的な名前。Descriptionには課題の内容、WhatとWhyを書きます。
他のレポジトリのIssueの書き方を参考にしたらいいと思います。
-
Issue に強弱をつける。
IssueにLabelsをつけて、研究の必須度、タスクの種類に分けるのもいいですし、
Milestonesをつけて、Issueの期日を設定するのもよいです。
2. プロジェクト機能を活用する
Issueを作ったら、次はどのIssueから取り組んでいくかを決めます。
- ProjectsタブからCreate new projectを選択。
- 適当なTitleをつける.
- テンプレートは個人作業ならAutomated Kanban, 複数人で開発するなら(コードレビューを行ったりする)なら Automated Kanban with reviews を選択すれば丸いです。
- 最初は何もないので、右のAdd cardsよりIssueをとってきてTo doに追加します。
(自動でカード追加するトリガーというものも設定できるみたいです.) - 取り組むIssueが決まったら、そのIssueをIn progressに移動します。
これでPlanは完了しました。
Do: 開発する。
Issueに取り組みます。
Issueがプログロム開発に関係していて, Githubの本来の機能(ソースコード管理)を使う場合の具体的なコマンドは他を参考にしてください。ここでは概略だけ。
-
IssueのIDを確認する (IssueのIDをユニークに決定されます)
-
作業ブランチの名前に
IssueのIDをつける. ユニークなIDを使って, branchを作ります。
> git checkout -b #12_test -
開発する。
これでDoは完了します。
Check: 確認・レビューする。
Issueの内容に沿ったことができたか、振り返って確認します。
ここでもプログラムに関わるところは、概略のみ示します。
- オリジンの作業ブランチにプッシュ
git add .
git commit -m “add/implementation_hogehoge”
git push origin #12_test
// githubリモートの#12_test というブランチにpush.
- オリジンの作業ブランチをMasterブランチにマージ
- Create pull request
pull requestの内容は実験ノートを書くのもいいですし、共同開発できるならちゃんとフォーマットにのって書いたほうがいいですね。何も書かないのもありですかね。
-
レビューをお願いする
-
ReviewersにGithubのUserを設定して、レビューしてくれる人を設定します。レビュワーから認可してもらえないと、Merge Pull Requestが送れないはずです。
AssigneesはPull Requestの責任者？担当者ってイメージです。
b. Merge Pull Request
レビュワーの認可が終わったり、Masterブランチとのコンフリクトがなければ無事にMerge pull requestができるはずです。
これでCheckは終わりです。
Action: 再計画。
とりあえず ProjectのIssuesを In Progressから、Doneに移動させましょう。
また、Checkの内容を踏まえて、新しいIssueを作ったり、Issueの優先度を見直したりしてください。
追記
- Slackを導入している研究室なら、SlackにGithubのアプリを導入することによって通知がSlackにいくようになります。ちょっとした議論等はその辺でやることが多いです。