31
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

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

概要

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

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

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

メリット

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

Issueそのものについてはこちらの書籍が非常に参考になります。

使い方

初期設定

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

研究のPDCAサイクル

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

Plan: 計画

1. Issueをつくる。

何はともあれ Issueを作ります。Issueは直訳すると課題, IssuesはTO-DOリストみたいなものです。
プロジェクトに今ある課題を全部Issueとして作りましょう。

  1. Issues タブからNew Issueを選択
  2. Title にはわかりやすい端的な名前。Descriptionには課題の内容、WhatとWhyを書きます。 他のレポジトリのIssueの書き方を参考にしたらいいと思います。
  • 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に追加します。 (自動でカード追加するトリガーというものも設定できるみたいです.)
  5. 取り組むIssueが決まったら、そのIssueをIn progressに移動します。 これでPlanは完了しました。

Do: 開発する。

Issueに取り組みます。

Issueがプログロム開発に関係していて, Githubの本来の機能(ソースコード管理)を使う場合の具体的なコマンドは他を参考にしてください。ここでは概略だけ。

  1. IssueのIDを確認する (IssueのIDをユニークに決定されます)

  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.

  1. オリジンの作業ブランチをMasterブランチにマージ
    1. 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にいくようになります。ちょっとした議論等はその辺でやることが多いです。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
31
Help us understand the problem. What are the problem?