【学生必見】Github Flowでアプリケーション開発

Githubを利用してアプリケーションの開発を進めていく際、具体的にどのように進めていけば良いのか分からないと困ったことはありませんか？Githubをあまり使ったことがない方であれば、一度はこのような疑問を抱いたことがあるかもしれません。そこで、今回はGithubを利用する上で欠かせないGithub flowについて詳しくご紹介致します。この記事を読めば、今まで疑問だったGithubを利用したアプリケーション開発のフローを素早く理解していただくことができます。

この記事の目次

1 Github flowとは？
- 1.1 Github flowが多くの人々に利用されている理由
2 Github flowの流れ
3 Github flowとGit flowの違い
4 Github flowの原則
5 Github flowでの開発に役立つツール
- 5.1 Github Desktop
- 5.2 SourceTree
6 まとめ

Github flowとは？

まず始めに、Github flowとは何か？と感じた方もいると思います。

Github flowとはGithub社が実践している開発フローのことで、開発フローがとてもシンプルで分かりやすいため、学習コストが低いという利点があります。

Github flowが多くの人々に利用されている理由

Github flowはその開発フローのシンプルさ、分かりやすさのために多くの企業がチーム開発に取り入れており、個人の開発者にも利用されています。
例えば、企業などで複数人が開発に関わっていることを想定した場合、以下の２つを比べると管理しやすいのはどちらでしょうか。

１.それぞれが個人のやりやすい開発フローに沿って好き勝手に開発する企業

２.開発フローを統一し全員が守っている企業

もちろん、後者の方が管理しやすいと思った方がほとんどだと思います。答えは「2.」です。
開発フローを統一することで、属人的な要素がなくなり、複数人で開発しても効率よく開発することができます。
Gitを利用した開発フローには、この記事で紹介していくGithub flowの他にもGit flowがあります。このGit flowに関しては後で詳しく紹介していきます。

Github flowの流れ

まず始めに、Github flowの開発フローを流れでまとめて見ていきましょう。

全体の開発フローは以下です。

１.masterブランチを常にデプロイできる状態にしておく

２.新しい作業をするときはmasterブランチを作成し、そのブランチで作業する

３.作成したローカルリポジトリのブランチにコミットする

４.同名のブランチをGithubのリポジトリに作成し、定期的にプッシュする

５.助けてほしい時やフィードバックがほしいときはプルリクエストを作成し、プルリクエストでやりとりする

６.他の開発者がレビューし、作業終了を確認したらmasterブランチにマージする

７.masterブランチへマージしたら、直ちにデプロイする

以上がGithub flowの全てです。

基本的には特定の作業をするブランチを作成するだけなので、作業を始めてデプロイするまでの過程がとてもシンプルです。それでは流れを１つ１つ確認していきましょう。

masterブランチを常にデプロイできる状態にしておく

Gitではリポジトリ作成時にmasterブランチが作成されます。このmasterブランチにあるソースコードが常にデプロイできる状態に保つというルールです。

デプロイは、アプリケーションを本番環境にアップロードすることです。

新しい作業をするときはmasterブランチを作成してそこで作業する

新しい作業をするときは、masterブランチから新しいブランチを作成します。新機能の追加でもバグの修正でも、新しいブランチを作成するという作業は変わりません。新たに作成するブランチ名には、作業している内容が分かるような名前をつけましょう。

作成したローカルリポジトリのブランチにコミットする

作成したブランチでどのような作業をするのか明確になっています。ブランチ名に沿った作業のみをそのブランチで行います。もし別の作業をする際には、masterブランチから別の作業用のブランチを作成します。
作業内容をコミットする際は、コミットメッセージからどのような作業内容か伝わるように心がけましょう。

同名のブランチをGithubのリポジトリに作成し、定期的にプッシュする

２で作成したブランチはローカルリポジトリ内にしか存在しないので、チームの他の開発者は誰がどのようなブランチを作成したか分かりません。なので、ブランチ作成時やコミットをした際に、開発者が作成したブランチをリモートリポジトリへプッシュしてください。

作業中の内容やすべてのローカルリポジトリで作成されたブランチをプッシュすることで、そこで、今回はGithubを利用する上で欠かせないGithub flowについて詳しくご紹介致します。

この記事を読めば、今まで疑問だったGithubを利用したアプリケーション開発のフローを素早く理解していただくことができます。現在誰が何をしているのかをリモートリポジトリにあるブランチ一覧を見るだけで把握できるようになります。

助けてほしい時やフィードバックがほしい時はプルリクエストを作成しプルリクエストでやりとりする

プルリクエストとは、リモートリポジトリにてマージする際に挟む確認作業のことです。しかし、プルリクエストはmasterブランチにマージしてほしい時だけ作成するものではありません。

複数人開発では、masterブランチへマージするタイミングよりもずっと前からプルリクエストを作成し、レビューなどのフィードバックをもらいながら開発するのが効率が良いです。

他の開発者がレビューし、作業終了を確認したらmasterブランチにマージする

ブランチでの作業が完了したら、プルリクエスト上で他の開発者からレビューを受けてください。他の開発者の目を通すことによって、思い込みやミスによるバグがmasterブランチに混ざることを防ぐことができます。もし作業内容に問題があれば指摘してもらい、修正を行いましょう。

masterブランチへマージしたら、直ちにデプロイする

プルリクエストによって、ある開発者が開発した機能はmasterブランチにマージされる前に第三者が確認できます。しかし、確認を挟んでもバグが混入することがありうるため、masterブランチへのmergeが行われた時は、マージ直後に必ずmasterブランチの内容が正常にデプロイできるかどうかをチェックする必要があります。

Github flowとGit flowの違い

出典：Git flow

そもそもGithub flowやGit flowは、Gitにおけるリポジトリでバージョン履歴を管理しながら開発を進めていく上で、効率よく作業できるようなワークフローのことなので、最終的な着地点は同じなのです。

その中でもGithub flowはGit flowを簡略的にした開発者にとって分かりやすく、使いやすくした開発フローであると言えます。

Github flowとGit flowの違いに関して例を上げると、開発を進めていく際にmasterブランチだけでなく、developmentブランチが存在します。このflowにおいて、masterブランチはリリースされたバージョンを管理するために使われ、普段の開発でプルリクエストを出した後のマージ先はdevelopmentブランチとなります。

この他にもGit flowでは役割ごとのブランチがあり、明確に使用する意図がわけられているため管理がしっかりしているという反面、Github flowですらあまり慣れていない方にとっては、かなり複雑であると言えるでしょう。

そのため、Git flowについては掘り下げて説明しませんが、興味のある方は調べてみるのも良いと思います。

上記のような理由から、開発する際にはGithub flowで実践していただくことをおすすめします。

この記事のハッシュタグ

Github flowの原則

上記でGithub flowにおける一連の開発フローの流れ簡潔に紹介しましたが、ここからは開発の際に特に重要であるGithub flowの原則について幾つか紹介します。

masterブランチとデプロイ

materブランチとデプロイに関しては、Github flowの１番で説明しました。

ここでは、そもそもブランチとは？やデプロイとは？という事に絡めてGithub flowの原則についても説明します。

ブランチとは、簡単に言うとリポジトリで管理しているプロジェクトの履歴の一つで、リポジトリは必ずブランチを持っています。なぜなら、リポジトリのバージョン管理はブランチ上で行われているためです。そして、開発者は必ずどこかのブランチ属している状態となります。

masterブランチとは、リポジトリに最初のコミットを行うと自動で作成されるブランチであり、これが大元のブランチとなることが多いです。

次にデプロイについて説明します。デプロイとはソースコードをAWSなどの本番環境に配備し稼働させることで、簡単に言うと、ローカル環境で開発したアプリケーションをネットワークを通じて誰でも利用できる状態にする作業のことです。

Github flowではデプロイまでのプロセスがシンプルに統一されているのも、多くの企業でこの開発フローが使われている理由の１つであります。

そして一番大事な原則は、Github flowの手順１番でも記述していますが、masterブランチは常にデプロイできる状態でなければいけません。

その理由を説明するために、開発者たちがmasterブランチに直接コミットしている職場を想定してください。この中の誰かのコミットにバグが混ざっていて、ユーザーに公開しているアプリケーションが正常に動作しなくなってしまうという事態になりかねません。
このようなことを防ぐために、masterブランチは常にデプロイできる状態とする必要があります。