GitHub のタスク管理やプロジェクト管理を利用した運用方法

Gitクラウド

GitHub の Issues(タスク管理)や Projects(プロジェクト管理)を利用した運用方法を、Git ワークフローに当てはめながら解説いたします。

素の Git によるソース管理の運用方法やワークフローについては以前の記事で解説いたしました。
では、Git のホスティングサービスである GitHub を利用した場合の運用方法やその手順はどのような感じになるでしょうか。

GitHub を利用するメリットは、環境構築のしやすさやブラウザ画面上からの操作で運用が視覚的にわかりやすいことですね。
特に Git 標準にはないプルリクエストの機能は、今やソース管理の運用上かかせないものであり、GitHub(もしくはその他の Git プラットフォーム)を使わない選択肢はほとんどなくなってきているのではないでしょうか。

また、Issues や Projects という機能により、単なるソース管理という枠を超えてかなり充実したサービスとなっています。
これらの機能を利用しながら、Git ワークフローの実際の運用手順について説明したいと思います。

GitHub の環境構築の手順については、以下の記事を参考にしてください。

参考: GitHub の環境構築から git clone までの手順


プロジェクトの作成
ユーザアイコンのメニューより Your profile を選択します。

GitHub your profile

上部タブの Projects を選択し、「New project」をクリックします。

GitHub New project

プロジェクト作成のウィンドウが表示され、4つのテンプレートの選択が出てきます。

GitHub 4つのテンプレート

ここでは Board を選択します。
ボードレイアウトはカンバン方式(ジャストインタイム方式)による issue 管理を実現します。
タスクアイテムの追加も容易で、アイテムの移動もマウス操作で簡単にできます。

Board を選択すると、以下のようなプロジェクト画面が表示されます。

GitHub プロジェクト画面

TodoIn ProgressDone の3つのステータスのカラムが作られていますね。
カンバン方式で扱う各工程がこのカラムにあたります。
カラムは「+」をクリックすることで簡単に追加できます。
また、カラム名をシングルクリックすることですぐに変名ができます。

ちなみに Team backlog のテンプレートだともう少し詳しい工程に割り振られます。

GitHub Team backlog

これでプロジェクトが作成できました。

GitHub プロジェクト一覧


リポジトリとプロジェクトの関連付け
リポジトリとプロジェクトを関連付けします。
リポジトリのトップページの上部タブ Projects をクリックします。

GitHub リポジトリ画面

右上の「Add project」をクリックし、該当するプロジェクトを選択します。
複数のプロジェクトが該当する場合は複数選択します。

GitHub プロジェクト追加

リポジトリとプロジェクトが関連付けされました。
これでリポジトリのトップ画面からもプロジェクトの画面にいけるようになりました。

GitHub リポジトリとプロジェクトの関連付け


プロジェクトの設定
プロジェクト画面の右上「」のアイコンをクリックするとメニューが現れますので、Settings を選択します。

GitHub プロジェクトの設定

・Project settings
プロジェクト名や README、public/private などを設定できます。
プロジェクトの削除・クローズもここでできます。

GitHub Project settings

Manage access
プロジェクトメンバー(コラボレータ)の招待やアクセス権(Read/Write/Admin)が設定できます。

GitHub Manage access

Read
Team あるいは個人はプロジェクトを見ることができます。

Write
Team あるいは個人はプロジェクトを編集できます。

Admin
Team あるいは個人はプロジェクトを見て編集でき、新しいコラボレータを追加できます。

・Custom fields
プロジェクト画面に表示されるフィールドを設定します。
デフォルトで Status というフィールドが存在し、ボードレイアウトのカラムに対応しています。
Status フィールドの設定もここからできますが、ボードレイアウトから行う方が良いかと思います。

GitHub Custom fields

新しくフィールドを作成するには、左メニュー「+New field」をクリックし、フィールド名と種類を選択して「Save」ボタンをクリックします。

GitHub カスタムフィールドの作成

作成したフィールドは、テーブルレイアウトのカラムとして表示されます。
ここでは優先度というフィールドを作成してみました。

GitHub テーブルレイアウトのフィールド表示

この画面の「」でもフィールドの追加はできるようです。
ボードレイアウトでもこのように表示されます。

GitHub ボードレイアウトのフィールドの表示

フィールドの設定はそのままにして、表示/非表示だけ変えることも可能です。
先ほどの Setting の画面からプロジェクト画面に戻り、View 1 タブのプルダウンをクリックして、レイアウトメニューを出します。

GitHub プロジェクト画面の表示設定

Table / Board の表示切り替えもここでできますね。
fields の行をクリックすると表示設定が出てきます。
表示したいものを Hidden fields から選択、非表示にしたいものを Visible fields から選択します。

GitHub フィールドの表示設定


ワークフロー
issue の作成から本番リリースまでの手順を、Git ワークフローにあてはめながら説明します。
いまいちな例ですが、使っていくとこんな感じになります。

GitHub プロジェクト画面ボードレイアウト全体

ちなみにこの例ではテンプレートからいくつかのカスタマイズを行っています。

・レビュー待ち(In Review)と保留(On Hold)のカラム追加
・ラベルと優先度(独自に作成)のフィールド表示


1. タスクの発生(No Status → Todo)
不具合を修正したい、新機能を追加したいなど、なんらかのタスクが発生したら、Todo カラムにアイテムを作成します。
Todo カラム下部の「+Add item」をクリックすると入力欄がでてきますので、タイトルを入力します。

GitHub タスクアイテムの作成

タスクアイテムが作成されました。

GitHub 新規タスクアイテム

作成したアイテムを issue 化します。
アイテムにマウスを置くと「」が現れますのでこれをクリックし、「Convert to issue」をクリックします。
リポジトリが複数ある場合はリポジトリ選択のウィンドウが出てきますので、該当するリポジトリを選択します。

GitHub タスクアイテムの issue 化

タスクアイテムが issue 化され、リポジトリと紐づきました。

GitHub タスクアイテムと issue およびリポジトリの紐づけ

もちろん issue を作成してからプロジェクトに紐づけることもできます。
リポジトリトップ画面の上部タブ issues をクリックします。

GitHub リポジトリ画面 issue タブ

右上の「New issue」をクリックします。

GitHub issue 一覧画面

issue のタイトルやコメントを入力し、右側メニューの Projects の歯車をクリックして issue をプロジェクトに紐づけます。

GitHub issue 入力画面

Submit new issue」をクリックして保存します。
Project の Status が No status になっているので、Todo に変更します。
Status: No status をクリックすると選択メニューが現れます。

GitHub issue 画面からのプロジェクトステータスの変更

プロジェクト画面に戻ると issue が Todo カラムの中にタスクアイテムとして追加されていますね。

GitHub issue 画面からのタスクアイテム追加

タスクアイテムのタイトルをクリックすると編集画面が出てきます。
右側メニューにはアサインする人、ラベル、マイルストン、Status、自身で作成したフィールド(ここでは優先度)の設定ができるようになっています。

GitHub タスクアイテムの編集画面

下図はラベルの選択画面です。

GitHub タスクアイテム編集画面のラベル選択

ラベルや優先度も設定すると、各アイテムはこんな感じに表示されるようになりました。

GitHub プロジェクト画面ボードレイアウト


2. タスクのアサイン(Todo → In Progress)
issue に対して担当者を割り振ります。
タスクアイテムのタイトルをクリックして issue 編集画面を開きます。
右側メニュー Assignees の「Add assignees…」をクリックすると、メンバーの選択画面がでてきますので、アサインするメンバーを選択します。

GitHub 担当者のアサイン

アサインされた担当者はタスクアイテムを In Progress に移動させ、実際の作業を開始します。

GitHub タスクアイテムの移動

ワークフロー:手順 ①
① ローカルのdevelopブランチを作成(すでに作成済みであれば最新の状態に)し、これを元に作業ブランチを作成。

# ローカルのdevelopブランチの作成
>git checkout develop
Switched to a new branch 'develop'
Branch develop set up to track remote branch develop from origin.

# ローカルのdevelopブランチを最新の状態に
>git pull origin develop
From https://github.com/yanox2/TestRep
 * branch            develop    -> FETCH_HEAD
Already up to date.

# git checkout -b [作成ブランチ名] [派生元ブランチ名]
>git checkout -b feature/issue02 develop
Switched to a new branch 'issue02'


3. プルリクエスト(In ProgressIn Review
修正が完了したら作業ブランチをコミットし、リモートにあげます。

ワークフロー:手順 ②③
② 修正をcommitする。

>git add -A
>git commit -m "不具合の修正"
[feature/issue02 d523861] 不具合の修正
 1 file changed, 3 insertions(+)
 create mode 100644 sample.php

③ 作業ブランチをリモートにあげる。

>git push origin feature/issue02:feature/issue02
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 322 bytes | 322.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote:
remote: Create a pull request for 'feature/issue02' on GitHub by visiting:
remote:      https://github.com/yanox2/TestRep/pull/new/feature/issue02
remote:
To https://github.com/yanox2/TestRep.git
 * [new branch]      feature/issue02 -> feature/issue02

作業ブランチをリモートにあげると、リポジトリトップ画面にプルリクエストのボタンがでてきます。

GitHub プルリクエストの作成

Compare & pull request」をクリックすると、当該ブランチに対応したプルリクエスト画面がでてきます。
base:developに変更し、compare: を当該作業ブランチ(feature/issue02)に変更します。
(この手順の場合、compare: はすでに当該作業ブランチが選択された状態になっています)
コメントを入力して「Create pull request」をクリックします。
これでプルリクエストが作成されました。

GitHub プルリクエストの作成2

通常のプルリクエスト画面からの場合は、リポジトリトップ画面の上部タブ Pull requests をクリックします。
New pull request」をクリックしてプルリクエスト作成画面へいきます。

GitHub プルリクエスト画面

base:developに、compare:feature/issue02に変更します。

GitHub プルリクエスト画面ブランチの選択

Create pull request」をクリックすると、先ほどのプルリクエスト作成画面までたどりつけます。

GitHub プルリクエストの作成

作成されたプルリクエストの画面です。
右側メニューでレビュアーやラベル等を設定できます。

GitHub 作成されたプルリクエストの画面

右側メニューで当該プルリクエストをプロジェクトにリンクできるようになっていますが、プロジェクトにリンクしてしまうとプルリクそのものが新たなアイテムとしてプロジェクトに作られてしまうようです。

issue と pull request でそれぞれ2つのアイテムになってしまうので、あまりお勧めではありませんが、プルリクエストのアイテムは Workflows の設定によって自動的にクローズできますので、2つあっても見づらいと感じなければプロジェクトにリンクしても良いかもしれません。

次にプルリクエストと issue を紐づけます。
右側メニュー Development の歯車をクリックすると issue の一覧がでてきますので、該当するものにクリックします。

GitHub プルリクエストと issue の紐づけ

これでプルリクエストと issue が紐づきました。

GitHub プルリクエストと issue の紐づけ

issue 画面を確認してみましょう。
一覧から当該 issue へいき、右側メニューの Development が以下のようになっていれば紐づけがうまくできています。

GitHub issue とプルリクエストの紐づけ

もしうまく紐づいていないようであれば、歯車をクリックするとリポジトリおよびブランチの一覧がでてきますので、該当するものを選択して「Apply」ボタンをクリックします。

GitHub issue とプルリクエストの紐づけ

プロジェクト画面に戻り、当該アイテムのタイトルをクリックして編集画面を見てみましょう。

GitHub タスクアイテムとプルリクエストの紐づけ

プルリクエストへのリンクができています。
これでタスクアイテムとプルリクエストと issue が紐づきました。

アイテムの編集画面に表示されるプルリクエストへのリンクですが、なぜか開いた直後はリンクが表示されず、No linked pull requests となるようでした(Chrome、FireFox、Edge)。

ブラウザのタブで一旦別の画面を表示して元のタブに戻ってくるとリンクが表示されるようです。

最後に当該アイテムを In Review に移動させます。

GitHub タスクアイテムの移動


4. プルリクエストの承認(In ReviewDone
リクエストを確認し、問題がなければプルリクエストを承認します。
プルリクエストの画面より該当するプルリクエストを選択します。
Merge pull request」をクリックするとリクエストの承認と同時に作業ブランチがリモートのdevelopブランチにマージされます。

GitHub プリリクエスト画面

なお、マージに関しては3つの選択肢があります。

GitHub マージの種類

Create a merge commit
マージコミットを作成してマージします。
fast-forward させない--no-ffオプションを指定したマージです。
本サイトではこれを推奨します(デフォルトもこれです)。

>git merge --no-ff feature/issue02

Squash and merge
マージコミットが作成されますが、コミットがまとめられて元のコミットの情報がなくなります。

Rebase and merge
マージの際に fast-forward が行われます。
ログはきれいになりますが、マージの取り消しが難しくなります。

Create a merge commit の場合、コメント入力を入力し、「Confirm merge」をクリックします。

GitHub マージコミット

承認が完了し、プルリクエストはクローズされました。

GitHub プルリクエストの承認

また、作業ブランチはリモートのdevelopブランチにマージされました。

GitHub 作業ブランチのマージ

リモートにあげた作業ブランチは必要なくなったので削除します。
ブランチを切り替えるプルダウンをクリックし、View all branches をクリックします。

GitHub ブランチ一覧の表示

削除するブランチのごみ箱アイコンをクリックします。

GitHub 作業ブランチの削除

これでリモートの作業ブランチは削除できました。
ちなみにプルリクエストが承認されたと同時に自動的にブランチの削除を自動で行うこともできます。
リポジトリトップ画面の Settings をクリックし、下図の項目にチェックを入れます。

GitHub マージされたブランチの自動削除

ただし、developブランチをmainブランチにマージしたときなど、思わぬブランチが削除される可能性がありますのでこの設定はお勧めではありません

最後にアイテムを Done に移動させて終了です。

GitHub タスクアイテムの移動

とりあえずこれで個々の issue 的には完了ですが、全体としては修正の本番リリース(デプロイ)を行う必要があります。


5. 本番リリース(デプロイ)
通常ではdevelopブランチへのマージはステージング環境に繋げているはずなので、個々にマージされた修正をステージング環境にて正常動作するかテストを行います。
テストで問題がなければdevelopブランチをmainブランチへマージ、すなわち本番環境へのデプロイを行います。

参考: Git のフックを利用したデプロイの方法

デプロイは Git のフックを利用して行いますが、GitHub では Actions という機能を利用して行うことができます。

基本的には本番リリースの権限を持つ人は、限られた人数の専任者であるべきです。
したがってデプロイ(すなわちmainブランチへのマージ)においては、専任者へプルリクエストを行い承認を得るという運用ルールがあった方が良いかと思います。

リポジトリトップ画面の上部タブ Pull requests をクリックし、「New pull request」をクリックしてプルリクエスト作成画面へいきます。

GitHub プルリクエスト画面


base:mainに、compare:developに変更します。

GitHub プルリクエスト作成画面

developブランチの履歴やソースコードの差分を確認し、「Create pull request」をクリックします。

GitHub プルリクエスト入力画面

コメントを入力して「Create pull request」でプルリクエストは完了です。
右側メニューでレビュアー(専任者)やラベルを設定できます。

GitHub プルリクエスト画面

プロジェクトとリンクさせればプロジェクト画面のカラムに表示されます。

GitHub プルリクエストアイテムの表示

専任者はこのアイテムをクリックすることでプルリクエスト画面に飛ぶことができます。
プルリクエストの承認は 4. の手順と同じです。
承認が完了したら、developブランチがmainブランチにマージされ、本番リリースが行われます。

GitHub プルリクエストの承認

このアイテムはプルリクエストが承認されたと同時に自動的に Done に移動します。
これは Workflows にそのような設定がされているからです。
プロジェクト画面の右上「…」のアイコンをクリックするとメニューが現れますので Workflows を選択します。

GitHub Workflows の設定

デフォルトではアイテムが close したときのフローと、プルリクエストがマージされたときのフローが設定されています。

GitHub デフォルトの Workflows の設定

以上が一通りの流れとなります。


参考: Git ワークフロー(ブランチモデル)とその手順
参考: Git のフックを利用したデプロイの方法

コメント