2.GitとGitHub Flow

本章では，本稿において我々が対象とする分散型版管理システムGitとGitのブランチ機能を前提としたソフトウェア開発フローの一つであるGitHub Flowについて述べる．

2.1 分散型版管理システムGit

分散型版管理システムでは，複数の開発者の開発環境（ローカル）とサーバ上（リモート）にそれぞれリポジトリが存在する．分散型版管理システムを用いた開発は下記の手順で行われる[saito2015]．

• ローカルリポジトリを最新のリモートリポジトリに更新する（プル）
• ローカル開発環境で開発を行い，ソースコードの変更をローカルリポジトリに書き込む（コミット）
• ローカルリポジトリの変更内容をリモートリポジトリに反映する（プッシュ）

ここでリポジトリに書き込まれる各コミットにはコミッター，コメントといった情報の他に直近のコミット（親コミット）へのポインタが格納される[C. Scott]．さらにGitではブランチ機能を利用することで，コミット履歴を分岐させることができる．分岐したコミット履歴は相互に影響を与えないため，新機能のテストやバグ修正を同時に進めるといった柔軟で安全な開発が可能となる．分岐後に作成されたコミット履歴を分岐前のコミット履歴に統合することをマージと呼ぶ．

図2.1-1はリポジトリ作成時に最初に生成されるmasterブランチからex1という名前のブランチを作成してコミットを行い，その後2種類の方法（fast forwardとno fast forward）でマージされたときにコミット履歴がどうなるかを示した図である．

図2.1-1 fast forwardなマージとno fast forwardなマージ

Gitでは，ブランチを作成すると対象となるコミットを指すポインタが作成される．図2.1-1では，ex1ブランチを作成してからコミットを行うことで，最新のコミットへとex1ブランチを示すポインタが移動する．この図にあるように，ブランチ作成後にmasterブランチでコミットを行わない状態で，ex1ブランチにおける変更をmasterブランチに統合する場合，2種類の方法でマージが可能である．図2.1-1左下をfast forwardなマージと呼び，右下をno fast forwardなマージと呼ぶ．fast forwardなマージでは，マージ先のブランチのポインタがマージ元のブランチのポインタと同じコミットへと移動する．一方，no fastforwardなマージでは，ex1ブランチでリポジトリに登録されたすべてのコミット内容を含み，複数の親を持つマージコミットと呼ばれる特別なコミットが作成・追加される．

2.2 GitHub Flow

GitHub FlowとはGitのリポジトリホスティングサービスGitHubを提供するGitHub社によって実際に運用されている開発フローである．GitHubはプルリクエスト[GitHub Inc.]と呼ばれる機能を提供している．プルリクエストはあるブランチを指定したブランチにマージすることをそのリポジトリの管理者にリクエストするための機能である[saito2015]．レビュー機能などと組み合わせることで，マージを複数の開発者のチェックを通してより安全に行うことができるようになる．GitHub Flowにおいてもこのプルリクエストが非常に重要な役割を果たしている．以下にGitHub Flowにおいて遵守すべき6つのルールを示す．

• R1: Anything in the master branch is deployable
• R2: To work on something new, create a descriptively named branch off of master
• R3: Commit to that branch locally and regularly push your work to the same named branch on the server
• R4: When you need feedback or help, or you think the branch is ready for merging, open a pull request
• R5: After someone else has reviewed and signed off on the feature, you can merge it into master
• R6: Once it is merged and pushed to ‘master’, you can and should deploy immediately

GitHub Flowにおいて最も遵守すべきルールとしてR1を挙げており，masterブランチに置かれるコードは常にテストが行われてからプッシュされ，デプロイ可能な状態を維持することを求めている．R2はブランチ名から現在どのような開発がどのブランチで行われているのかを把握しやすくするためのルールである．また，masterブランチからのみブランチを作成するようにすることで，ブランチの無秩序な乱立を防いでいる．R2とR3を組み合わせることで，誰がどのような作業を現在行っているかを把握しやすくすることを目指している．R4とR5も関連しており，マージを行う際，あるいは開発中に遭遇したトラブルがあった際などにプルリクエストを作成し，第3者からのフィードバックを受けることを求めている．R6はマージが行われた後に，R1でも述べたようにmasterブランチの内容を迅速にデプロイすべきであると述べている．

GitHub Flowでは，以上のシンプルな6つのルールをチームメンバ全員が遵守することを求めている．しかしながら，特に不慣れな開発者がチームに混ざっているような場合，開発フローに対する理解不足や開発フローの遵守状況を把握することが難しい．そのため本研究ではそういった状況の把握と支援を目的としたツールを開発し，使用する．