開発の流れ
本演習では，4～5人のチームでどうぶつしょうぎをGithub Flowにもとづいて開発する．じゃんけんゲーム開発とは異なり，この演習ではこちらからGitクライアントの操作方法を説明しない．じゃんけんゲーム開発での経験を活かし，チームで開発をすすめること．
Step0を実施する前に，下記を行う．
- Step0においてDoubutsuリポジトリを代表して作成し，初期コミットを行う主開発者を決定する．
- 共同開発者全員のGithubアカウントを確認する（Doubutsuリポジトリの共同開発者として主開発者が登録するため）
| 主開発者 | 共同開発者1 | 共同開発者2 | 共同開発者3 | 共同開発者4 | |
|---|---|---|---|---|---|
| 学生番号 | |||||
| 氏名 | |||||
| Github アカウント |
Step0は主開発者一人で実施する．その後，Step1以降を複数人で計画的に開発していくこと．また，常にGithub Flowを意識して開発を進めていくこと．
Step1以降の開発の流れ(例）
基本的にはじゃんけんゲームにおける開発の流れと同様に，リポジトリ作成及び初期コミットが完了した後は，各開発者がブランチを作成して自分のタスクを実施し，Pull Requestを作成・登録する．Pull Requestが登録されたら他の開発者がレビューを行い，問題なければそれをmasterブランチにMergeする．
以降ではStep1を例に具体的な流れを説明する．
Taskの割当
Step1には，Task1-1,Task1-2-a, Task1-2-b, Task1-2-c, Task1-3, Task1-4の6つのTaskが存在する．Task間には依存関係があり，Step1の場合は以下のように示されている．
Step1のTask間の依存関係
- Task1-1,1-2-*,1-3,1-4はこの順に実施すること
- Task1-2-a,1-2-b,1-2-cはTask1-1終了後いつどの順序で実施してもよい(Task1-3で必要なクラスなので，Task1-3より前に実装は完了させること）．
- すべてのエリアが正常に実装されているかはTask1-4完了時に確認できる．
この依存関係を利用し，どのTaskを誰が実施するかを決定する．なお，複数のTaskを一人でまとめて実施しても構わないが，Step毎に最低2人は開発を担当すること． 例えば，下記のような割当が考えられる．
| Task1-1 | Task1-2-a | Task1-2-b | Task1-2-c | Task1-3 | Task1-4 | |
|---|---|---|---|---|---|---|
| 開発 | 201X990 | 201X991 | 201X991 | 201X991 | 201X992 | 201X992 |
この例では，3人でTaskを分担しているが，2人以上であれば何人で分担しても構わない．また，Taskを担当する数は開発者間で過度のばらつきが無いように心がけること．Task担当数が極度に少ない場合は，別途課題等が与えられることもありうる．
レビュアーの割当
Github Flowに従うと，Taskが完了した後はPull Requestを作成し，レビューを他の開発者にしてもらう必要がある．そのため，レビュアーを最初に決定しておく．レビュアーはTask毎に決定するが，今回の事例では3人で開発を分担するため，ブランチは3つ，すなわちPull Requestも3つ作成されることになる．そのため，Task分担と連動する形で3名のレビュアーを決定することが望ましい（Task毎に異なるレビュアーを割り当てても問題ないが，その場合は特定のPull Requestを複数人でレビューすることになる）．
| Task1-1 | Task1-2-a | Task1-2-b | Task1-2-c | Task1-3 | Task1-4 | |
|---|---|---|---|---|---|---|
| 開発 | 201X990 | 201X991 | 201X991 | 201X991 | 201X992 | 201X992 |
| レビュー | 201X992 | 201X990 | 201X990 | 201X990 | 201X993 | 201X991 |
例えばこの表のように割当てられる．レビュアーを割り当てる際に守るべきことは開発者と同じ人がレビューを行わないようにすることである．なお，Task担当数同様レビュー担当数も開発者間で過度のばらつきが無いように心がけること．
開発
担当Taskにしたがって，ブランチを作成し，Taskを実施し，Pull Requestの作成・登録を行う．既に述べたように，ブランチは複数Taskをまとめて一つ作成しても構わない．今回の例の場合，201X991はTask1-2-a～1-2-cを含むブランチを1つ作成し，まとめて開発を行って構わない．いずれにせよ，ブランチ名は担当するTaskの内容を表現する分かりやすいものにすること．例えば，update_doubutsuのような更新するファイルやクラス名のブランチ名は望ましくない．その更新で何を行おうとしているかを考えて名前をつけること．
開発においてはTask間の依存関係に留意すること．今回の場合201X990が担当するTask1-1が完了するまでは201X991は開発を完了できない（Task1-1の成果物がなければ1-2-a等の成果物をコンパイルできないため）．また，Pull Request作成時には必ず一度はプログラムを実行し，コンパイルエラーや実行時エラーが発生しないことを確認しておくこと．
レビュー
Pull Requestの作成・登録を確認後，割当にしたがってレビュアーがレビューを行う．レビューを行うためにはまずPull Requestを作成したブランチをレビュアーが取得（Fetch）する必要がある(異常系シナリオE7参照)．その後，Task毎に指定されているレビュー項目に従い，対象ブランチを正常に実行できるか，実装内容がTaskで指定されたとおりになっているかを確認し，レビュー結果をPull Requestに対するコメントとしてGithub上で記述する．
レビュー結果がOKであれば，そのPull Requestを作成・登録した開発者がPull Requestの内容をmasterブランチにMergeする．
レビュー結果がNGの場合は，そのPull Requestを作成・登録した開発者がレビューコメントにしたがって修正作業を行い，Commit及びPushする．その後，再度レビュアーにレビューを行ってもらい，レビュー結果がOKになるまで繰り返す．
ここまでの内容をこのStepに割り当てられた開発者及びレビュアーが実施する．すべてのTaskの実装が完了し，すべてのブランチがMergeされた時点で次のStepに移行する．
エラー発生時の対応
レビュー実施時にエラーが発生した等でバグが見つかった場合は，担当開発者が修正し，Commit,Pushをやり直すだけで良い．ただし，Pull RequestをmasterブランチにMergeした後にバグが見つかった場合（動作はするが，仕様に準拠していなかった場合等も含む），新たに担当者（開発，レビュー）を割当，新しくバグを修正するためのブランチを作成し，修正作業を行うこと．ブランチ作成後の作業は通常の開発作業と同じで良い．