GitHub Issuesを使って共同開発の流れを繰り返し練習しよう

広告

目次

はじめに

これまでの演習では、GitとGitHubを使って、

  • ブランチを作る
  • コードを変更する
  • Commitする
  • Pushする
  • Pull Requestを作る
  • 他のメンバーがレビューする
  • Mergeする
  • mainを最新の状態にする

という共同開発の基本的な流れを練習してきました。

ここからは、新しく GitHub Issues を加えます。

ただし、最初から自由に機能を考えて開発するのではなく、まずは小さな課題を使って、

IssueからMergeまでの共同開発フローを何度か繰り返す

ことを目的にします。

最初の課題は、

「問題を1問増やす」

です。

実装そのものを難しくしすぎず、GitとGitHubを使った共同作業に集中してください。

今回の目的

今回の目的は、アプリを大きく改良することではありません。

次の流れを、グループだけで進められるようになることです。

Issueを作る
↓
Typeを確認する
↓
Assigneeを設定する
↓
作業用ブランチを作る
↓
コードを変更する
↓
Commit
↓
Push
↓
Pull Request
↓
レビュー
↓
Merge
↓
Issue完了
↓
mainを最新化

最初は手順を確認しながらでも構いません。

何度か繰り返す中で、少しずつ迷わず進められるようになることを目指します。

今回の役割

今回は、グループの中で役割を分けます。

例えば、

  • Issue作成担当
  • 実装担当
  • レビュー担当
  • 動作確認担当

です。

人数によっては、1人が複数の役割を兼ねても構いません。

大切なのは、毎回同じ人が同じ役割を担当し続けないことです。

演習を繰り返す中で役割を交代し、

Issueを書く側、実装する側、レビューする側

をそれぞれ経験してみてください。

Issueとは

Issueは、

これから行う作業をGitHub上に記録しておく仕組み

です。

例えば今回は、

問題を1問追加する

という作業をIssueとして登録します。

Issueを使うことで、

  • 何をするのか
  • 誰が担当するのか
  • どのような種類の作業なのか
  • その作業が終わったのか

をメンバー全員で確認できます。

Issueを使うメリット

グループ内で「次はこれをやろう」と口頭で相談するだけでも、作業を始めることはできます。

では、なぜIssueを使うのでしょうか。

やることが残る

口頭で決めた内容は、時間が経つと忘れてしまうことがあります。

Issueとして残しておけば、

「何をする予定だったのか」

を後から確認できます。

誰が担当しているか分かる

Issueの Assignees に担当者を設定しておけば、

誰がその作業を担当しているのか

をメンバー全員で確認できます。

作業の種類が分かる

GitHubでは、環境によってIssueに Type を設定できます。

代表的な種類には、

  • Task：作業
  • Bug：不具合修正
  • Feature：機能追加

があります。

これにより、

「これは不具合対応なのか、新しい機能なのか」

といった違いも分かりやすくなります。

作業の状態が分かる

Issueを見ることで、

まだ完了していない作業なのか、完了した作業なのか

を確認できます。

Pull Requestと作業内容をつなげられる

Issueには「何をしたいのか」を書き、Pull Requestには「実際にどのように変更したのか」が残ります。

例えば、

Issue #5
問題を1問追加する

というIssueに対してPull Requestを作り、

Closes #5

と記述して関連付けることで、

「このIssueを、このPull Requestで対応した」

という関係が分かるようになります。

過去の作業を後から確認できる

IssueとPull Requestが残っていれば、

  • なぜこの変更をしたのか
  • 誰が担当したのか
  • どの変更で対応したのか

を後から確認できます。

コードだけを見ても、なぜその変更をしたのか分からないことがあります。

Issueは、その変更の理由や目的を残す場所にもなります。

チーム全員で情報を共有できる

Issueを使う大きな理由は、

作業を個人の頭の中だけに置かないこと

です。

何をするのか
↓
誰が担当するのか
↓
どのような作業なのか
↓
どのように変更したのか
↓
レビューされたのか
↓
完了したのか

という流れをGitHub上に残すことで、チーム全員が同じ情報を確認できます。

Issueは単なる「やることメモ」ではありません。

チームで作業を管理し、その作業の経緯を残すための仕組み

として使うことができます。

Issueにはほかにも管理機能がある

Issueの画面には、このほかにも、

  • Labels
  • Milestone
  • Projects
  • Sub-issues

などの機能があります。

GitHubでは、これらを使ってIssueを分類したり、複数の作業をまとめて管理したりすることができます。

ただし、今回は、

Issueを使った共同開発の基本的な流れを覚えること

を優先します。

そのため、これらの機能については、

「こういう機能もある」

ということだけ知っておけば十分です。

今回は使用しません。

なぜ、すぐにコードを書き始めないのか

小さな変更であれば、すぐにコードを書き始めても作業自体はできます。

しかし、チーム開発では、

何をするのかを最初に共有する

ことが重要です。

誰かが勝手に作業を始めるのではなく、

Issue
↓
担当者
↓
作業
↓
Pull Request
↓
レビュー
↓
Merge

という流れを意識します。

今回は、この流れそのものを練習します。

Step 1：Issue作成担当を決める

最初に、今回のIssueを作成する担当者を決めます。

Issue作成も共同開発の大切な作業の一つです。

毎回同じ人がIssueを書かないように、演習ごとに担当を交代してみてください。

Step 2：Issueを作成する

Issue作成担当者は、GitHubで対象のリポジトリを開きます。

画面上部の Issues をクリックします。

次に、New issue をクリックします。

タイトル

今回は、

問題を1問追加する

とします。

本文

例えば、

クイズに新しい問題を1問追加する。
追加後、正しく出題されることを確認する。

とします。

Issueは長い文章を書くことが目的ではありません。

他のメンバーが読んで、

何をする作業なのか分かること

が大切です。

Step 3：Typeを確認する

Issueに Type が表示されている場合は、今回の作業がどの種類に当たるのか確認します。

代表的なTypeは、

Task
Bug
Feature

です。

今回の、

問題を1問追加する

は、新しい内容を追加する作業なので、Feature と考えることができます。

Typeを選択できる環境では、今回は Feature を設定してみましょう。

なお、TypeはGitHubの利用環境やリポジトリの設定によって表示されない場合があります。

表示されていなければ、この操作は飛ばして構いません。

Step 4：実装担当を決めてAssigneeに設定する

次に、

誰がこのIssueの実装を担当するか

をグループで決めます。

担当者が決まったら、口頭で決めるだけではなく、GitHubのIssueにも担当者を登録します。

Issueのページで Assignees から実装担当者を選択します。

これでIssueを見たときに、

「この作業は誰が担当しているのか」

が分かるようになります。

例えば、

Issue #5
問題を1問追加する

Type：Feature
Assignee：Bさん

という状態になります。

今回は1人を実装担当としてAssigneeに設定します。

他のメンバーは、

  • 追加する問題の内容を相談する
  • Issueの内容を確認する
  • 実装内容を確認する
  • Pull Requestをレビューする
  • 動作確認をする
  • Merge後のmainを確認する

といった役割を担当します。

共同開発では、

全員が同時にコードを書く必要はありません。

Step 5：作業用ブランチを作る

実装担当者は、作業用ブランチを作成します。

mainを直接変更しないようにしてください。

ここから先は、これまで練習してきたGitの流れです。

Step 6：問題を1問追加する

Visual Studioで、クイズの問題を1問追加します。

今回は、できるだけ小さな変更にします。

実装したら、必ず動作確認してください。

確認する内容は、

  • ビルドできるか
  • アプリが起動するか
  • 追加した問題が表示されるか
  • 正解判定が正しく動くか

です。

Step 7：Commitする

動作確認ができたらCommitします。

Commitメッセージには、変更内容が分かるように書きます。

例えば、

問題を1問追加

とします。

Step 8：Pushする

Commitした内容をGitHubへPushします。

GitHub Desktopを使っている場合は、これまでと同じ方法でPushしてください。

Step 9：Pull Requestを作る

GitHub上でPull Requestを作成します。

Pull Requestでは、

この変更をmainに取り込んでよいか

を他のメンバーに確認してもらいます。

IssueとPull Requestをつなげる

今回作成したIssueとPull Requestを関連付けます。

例えばIssue番号が、

#5

だった場合、Pull Requestの説明欄に、

Closes #5

と書きます。

これにより、

Issue #5
「問題を1問追加する」
        ↓
Pull Request
「問題を1問追加した変更」

という関係をGitHub上に残すことができます。

Step 10：レビュー担当が確認する

Pull Requestを作成した本人とは別のメンバーがレビューします。

レビュー担当は、

  • 本当に問題が1問追加されているか
  • ビルドできるか
  • アプリが正常に動くか
  • 追加した問題の正解判定が正しいか
  • 他の機能を壊していないか

を確認します。

問題がなければApproveします。

修正が必要であれば、コメントを使って実装担当者へ伝えてください。

Step 11：Mergeする

レビューが終わり、問題がなければmainへMergeします。

これでGitHub上のmainに変更が反映されます。

Pull Requestに、

Closes #5

のように記述してIssueを関連付けていれば、対象のIssueもCloseされます。

ここでIssueのページも確認してみてください。

Open
↓
Closed

となっていれば、Issueで管理していた作業が完了したことを確認できます。

Step 12：mainを最新の状態にする

誰かがMergeした後は、他のメンバーのPCにあるmainは古い状態のままです。

そのため、各メンバーは、

  1. mainへ切り替える
  2. FetchまたはPullする
  3. mainが最新になったことを確認する

という操作を行います。

ここまでできれば、今回の共同開発フローは一周です。

今回の共同開発フロー

もう一度まとめます。

Issue作成担当を決める
↓
Issueを作る
↓
Typeを確認する
↓
実装担当を決める
↓
Assigneeに設定する
↓
Branch
↓
実装
↓
Commit
↓
Push
↓
Pull Request
↓
IssueとPull Requestを関連付ける
↓
Review
↓
Merge
↓
IssueがClosedになったことを確認
↓
main更新

この流れを、何度か繰り返します。

1日目は「問題を1問増やす」

最初の課題は、

問題を1問増やす

です。

今回は、何を作るかを考えることよりも、

共同開発の流れを1周すること

を優先します。

50分ですべて終わらなくても構いません。

どこまで自分たちだけで進められるかを確認してください。

2日目以降は、少しだけ課題を変える

毎日まったく同じ課題では、作業が単調になってしまいます。

そのため、共同開発の流れは変えずに、変更内容だけ少しずつ変えていきます。

例えば、

2日目

終了メッセージを変更する

3日目

画面に表示する文章を1か所改善する

4日目

簡単な入力チェックを追加する

5日目

小さな表示機能を1つ追加する

といった形です。

課題は変わっても、

Issue
↓
Type
↓
Assignee
↓
Branch
↓
Commit
↓
Push
↓
Pull Request
↓
Review
↓
Merge
↓
Issue完了
↓
main更新

という基本の流れは変えません。

毎回、役割を交代する

反復するときは、課題だけでなく役割も交代します。

例えば4人グループなら、

1回目

  • Aさん：Issue作成
  • Bさん：実装
  • Cさん：レビュー
  • Dさん：動作確認

2回目

  • Bさん：Issue作成
  • Cさん：実装
  • Dさん：レビュー
  • Aさん：動作確認

3回目

  • Cさん：Issue作成
  • Dさん：実装
  • Aさん：レビュー
  • Bさん：動作確認

というように回していきます。

実装担当になった人は、Issueの Assignee にも設定します。

人数や進み具合に応じて、役割を兼任しても構いません。

重要なのは、

特定の人だけが毎回GitHub操作を担当しないこと

です。

なぜ同じ流れを繰り返すのか

GitやGitHubの操作は、一度説明を聞いただけでは身につきにくいものです。

特に、

  • Issueはいつ作るのか
  • Typeは何を表しているのか
  • Assigneeは何のために設定するのか
  • どのタイミングでBranchを作るのか
  • CommitとPushの違い
  • Pull Requestはいつ作るのか
  • IssueとPull Requestをどうつなげるのか
  • 誰がレビューするのか
  • MergeするとIssueがどうなるのか
  • Merge後に何をするのか

といった流れは、何度か経験することで少しずつ自然になります。

そのため今回は、

同じ問題を繰り返すのではなく、同じ共同開発フローを別の小さな変更で繰り返す

ようにします。

完成速度を競う演習ではありません

今回の演習は、

一番早く終わったグループが優秀

というものではありません。

重要なのは、

  • Issueを作れたか
  • Typeを確認できたか
  • Assigneeを設定できたか
  • Branchを使えたか
  • Commitできたか
  • Pushできたか
  • Pull Requestを作れたか
  • IssueとPull Requestを関連付けられたか
  • 他の人の変更をレビューできたか
  • IssueがClosedになったことを確認できたか
  • Merge後にmainを更新できたか

という一連の流れを経験することです。

50分で終わらなかったとしても、

どこで止まったのかが分かること

に意味があります。

講師は基本的に介入しません

今回は、これまで練習してきた内容を使って、

グループだけで共同開発の流れを回すこと

も目的です。

そのため、

「次はここをクリックしてください」

「次はこれをしてください」

といった細かな指示は基本的に行いません。

分からなくなった場合は、

  • グループ内で相談する
  • これまでのチュートリアルを確認する
  • GitHubの画面を確認する
  • この記事の手順を確認する

という方法で、まず自分たちで進めてください。

50分後に確認すること

毎回の演習終了時には、次の3つを確認します。

どこまで進んだのか

どこで止まったのか

次に何をすればよいのか

例えば、

IssueとAssigneeの設定まではできたが、
作業用ブランチを作るところで迷った

でも構いません。

また、

Mergeまではできたが、
mainを最新化するのを忘れていた

という場合も、それが次回の改善点になります。

何回か繰り返したら、次の段階へ進む

この演習をずっと同じ形で続けるわけではありません。

何度か繰り返して、

グループだけでほぼ迷わず共同開発の流れを回せるようになった

ら、次の段階へ進みます。

次の段階では、

何を変更するかもグループで考える

ようにします。

最初の段階

何を作るかは決まっている
↓
Issueを作る
↓
共同開発の流れを練習する

次の段階

何を作るかもグループで考える
↓
Issueを作る
↓
Typeを考える
↓
Assigneeを決める
↓
共同開発を進める

という流れです。

ここまで進めると、

「これはBugなのか」

「Featureなのか」

「単純なTaskなのか」

という分類も、作業内容に応じて自分たちで考えられるようになります。

最終的に目指すところ

最終的には、講師から細かな指示がなくても、

何を変更するか相談する
↓
Issueを作る
↓
作業の種類を考える
↓
Assigneeを決める
↓
Branchで作業する
↓
Pull Requestを作る
↓
Issueと関連付ける
↓
レビューする
↓
Mergeする
↓
Issueの完了を確認する
↓
mainを最新にする

という流れを、グループだけで進められることを目指します。

GitやGitHubは、操作を覚えるだけではなく、

チームで開発を進めるために使えること

が重要です。

まとめ

最初は、

問題を1問増やす

という小さな課題から始めます。

その後も、変更内容だけを少しずつ変えながら、

Issue
↓
Type
↓
Assignee
↓
Branch
↓
Commit
↓
Push
↓
Pull Request
↓
Review
↓
Merge
↓
Issue完了
↓
main更新

という共同開発の流れを繰り返します。

そして、Issue作成・実装・レビュー・動作確認などの役割も交代します。

Labels、Milestone、Projectsなど、Issueにはさらに多くの管理機能がありますが、最初からすべてを使う必要はありません。

まずは、

同じ共同開発フローを何度か経験して、どの役割でも迷わず動けるようになること

を目指してください。

その流れに慣れてきたら、

何を作るか、どの種類のIssueなのかも自分たちで考える共同開発

へ進んでいきます。

訪問数 11 回, 今日の訪問数 11回

広告

C#

Posted by hidepon