「GitHub Flow」で共同開発する3つのメリット

現在とりくんでいる42 Tokyoの課題にて、入学してから初めて、2人1組のチームで開発をおこなっています。

入学試験のPiscineでは、3、4人で1組のチームで開発をおこなったことはありましたが、その時はGitHubは使っていませんでした。（自分をふくめて、メンバー全員がGitHubに慣れているわけではなかったため。）

今回はじめてGitHubを使った共同開発をしているのですが、便利すぎて驚いています。

共同開発の方法はいくつか種類があるようですが、ぼくのチームは「GitHub Flow」を使用していました。

名前の似ている「GitHub Flow」と「git-flow」の違いは、以下の記事が図解しているのでわかりやすいです。

【図解】git-flow、GitHub Flowを開発現場で使い始めるためにこれだけは覚えておこう

GitHub Flowを実際に体験してみて、GitHub Flow良さは3つあると思いました。

① Issueでコードの問題やバグを管理

GitHub上の「Issue」に、現在かかえている課題を列挙することによって、すべての課題を一覧することができます。

また、誰がどのIssueに取り組むかを決めて、アサインすることもできるので、誰がなにに取り組んでいるかも一網飄然です。

それぞれの課題にたいしてブランチを切り、仮のプルリクエスト（draft pull request）を作成しておけば、そのプルリクエストにIssueの割り当ても可能なので、どのブランチでどのIssueに取り組んでいるのかも分かるようになります。

このIssueが空になること＝完成なので、ゴールまでの道のりがわかりやすく、モチベーションも保つことができます。

② やり方が簡単

「git-flow」ではさまざまなブランチのルールを覚える必要がありますが、「GitHub Flow」では基本的にはmainブランチと、取り組む課題のブランチだけとなり、管理が簡単です。

「GitHub Flow」のルールは以下となります。
・mainブランチは、常時デプロイ可能な状態を保つ
・全てのブランチはmainブランチから作成する
・作業内容が分かるようなブランチ名をつける
・作業中のブランチは定期的にプッシュする
・Githubのプルリクエストを利用してレビューを行なってから、mainブランチにマージする
・mainブランチにマージしたらデプロイする
・デプロイ後は速やかに作業していたブランチを削除する

少し多いと思うかもしれませんが、一番重要なのは「mainブランチは、常時デプロイ可能な状態を保つ」ことで、とりあえずここだけ押さえておけば、最初は大丈夫かと思います。

③ 修正前と修正後の違いがわかりやすい

GitHubを使えば、どこで修正があったのかを、元のコードと修正後のコードを比較することができるので、違いがわかりやすくて便利。

GitHubのサイト上で比較するので、操作も簡単です。

離れたコミット間の差分の確認するには少し手間がかかりますが、下記のサイトを参考にすれば、おこなうことができます。

GitHub – コミット間・ブランチ間の差分(Diff)の確認方法・見方

ただやはり、この作業は面倒なので、「コミットをまとめる方法」を習得し、レビュワーが確認しやすいように、コミットを整理することができたらいいなと思いました。

おわりに

現在、Gitの仕組みを知り、使いこなすために『Git入門コマンドライン演習80』をつかって学習をしています。

ただプログラマーになるために、GitHubの使い方にも慣れる必要があるので、今回のチーム課題を通じて、個人での開発でもGitHub Flowを使用していきたいと思いました。

「コミットをまとめる方法」が使えるようになれば、プルリクをレビューする人にたいして、コードの差分を見やすいようにできるため、今後学んでいきたいと思います。