github-logo

Github-flowで実践する初心者でも取り組みやすいGitワークフロー


Gitのワークフローとは

Git/Githubを利用して複数人で開発を進める場合、どのようにして進めるかを予め決めて運用しないといけません。

オープンソースの開発などでは、開発に加わりたい人がGithubにあるコードをForkし、CloneしてからPull Requestを送り、それが良いものであればマージするという手法をとっています。

しかし、実際の会社などでのプロジェクトでは非効率であり、役割分担などがしにくいため、Forkをしない方法でやる必要があります。

 

Git-flowの問題点

Gitでよく使用されるワークフローとして、Git-flowとGithub-flowというものがあります。

Git-flowは古くから使われている手法で、Github-flowは2011年にGithub社員のScott Chacon氏がブログで紹介してから広まったものです。Scott Chacon氏は、git-flowは素晴らしいと思うと答えている一方で、ほとんどの開発者や開発チームが実際に必要とするよりも複雑すぎやしないか、という問題点を指摘しています。

GitFlowMasterBranchGit-flowの図解

引用:A successful Git branching model

 

 

Github-flowの流れ

gitflow上がGithub-flowの流れの図解です。

流れは非常にシンプルで、基本的には追加機能などごとにmasterブランチからブランチを作成し、実装が終わったらMASTERブランチにマージします。

より詳細な流れとしては、

  1. MASTERブランチはいつでもリリース  / デプロイできる状態にしておく
  2. 新たな機能追加などを行うときはMASTERブランチからブランチを作成する
  3. 新たに作成したブランチに対してcommitし、定期的にPushする
  4. コードレビューや助けてほしい時にはPull Requestをしてやりとりする
  5. コードレビューが終了して問題無いと確認されたらMASTERブランチにマージする
  6. MASTERブランチへマージ後、すぐにデプロイ(リリース)する

です。

 

Github-flowのポイント

常にデプロイできる

Github-flowでは、MASTERブランチは常にデプロイ出来る状態にする必要があります。

そうすることで、いつでも新たにブランチを作成できて円滑にチーム開発を進めることができたり、追加したコードを迅速にユーザーに届けることができます。

Github-flowを生んだGithub社では1日に175回デプロイし、Amazon社は1時間に1000回デプロイすることもあるそうです。

これだけのデプロイを行うためには、MASTERブランチは常に安定させ、テストされてなかったり、ビルドを破壊するようなコードをMASTERに マージするようなことを絶対にしないようにする必要があります。

 

MASTERブランチからわかりやすい名前のブランチを作成する

新たな作業を始めるときはMASTERブランチからわかりやすい名前のブランチを新たに作成します。

わかりやすい名前というのは以下のように、

  • user-content-cache-key
  • submodules-init-task
  • redis2-transition

何をするブランチなのか想像しやすい具体的なブランチ名。

 

新たに作成したブランチに対してCommitする

新たに作成したブランチに対してCommitを行います。

Commitは出来る限り小さく行い、1つ1つのコミットの意味が明確で、同時にいくつもの変更を 1つのCommitにまとめないように注意してください。

 

定期的にPushをする

新たに作成したブランチに対して定期的にPushします。

MASTERブランチ以外のブランチに対してのPushは他の人の手を煩わせたり、混乱を引き起こすということがありません。

定期的なバックアップや、チームの他のメンバーとのコミュニケーションのためにも、定期的にPushするようにします。

 

いつでもPull Requestを使う

基本的にPull  RequestはMASTERブランチにマージしてほしい時に使います。

Github-flowではその目的以外に、助けてほしい時やまだ完成してないけれどコードレビューしてほしい時にもPull  Requestを使います。Github上でのPull Requestの機能では各行にコメントを入れられたり、@ユーザー名で誰かを読んだりできるので、円滑にコードレビューなどのコミュニケーションができます。

 

MASTERへのマージは、必ず他の開発者からレビューを受けた後

レビューと修正がおわり、もうデプロイしていいとなった時に初めてMASTERブランチへのマージを行います。

CIツールを用いてテストを実行し、ブランチに問題ないか確認した後、MASTERにマージします。

テストコードを書かずに手動で動作確認を行っていると、Github-Flowのような何度もデプロイするワークフローを採用することが困難なため、Github-Flowは継続的インテグレーションが行われていることが前提となります。

 

MASTERへのマージ後はすぐにデプロイ

MASTERへのマージ後はすぐに本番環境へデプロイするようにします。

毎度手動でデプロイするのも大変なので、CapistranoやFabricなどを利用して、MASTERにマージされた場合は自動デプロイできるようにしておく と便利です。

HerokuではCapistranoやFabricなどを自分で設定しなくてもすぐ自動デプロイできるので便利です。

 

まとめ

Gitを使用したブランチのワークフローのルールを予め決めておくことはとても大切です。

初心者が開発チームに入ることがある場合は特に理解しやすいGithub-Flowをおすすめします。

本サイトが運営するWebデザインのオンラインスクールが公開中!
以下のリンクからお申込みで、特別料金の70%OFF!

未経験からプロのWebデザイナーになる! 400レッスン以上の完全マスターコース
こちらのコースは全くの未経験の方が、プロのWebデザイナーとして働けるレベルになることを目的としたコースです。
・全422レッスン & 42時間! 通学スクール80万円相当の内容
・授業×チャレンジ課題で実践的なスキルが身につく!
・過去1100名以上のスクール卒業生を輩出した、 Webサービス運営企業・デザイナー輩出企業だからこそ作れるプログラム

Webやアプリの最新デザインツール Sketch3 |100レッスンの完全マスターコース
Sketch3未経験からプロレベルを目指す、充実したコースです。
Sketch3の単なる機能説明をするような、つまらないコースではなく、アイコン制作、ボタン作成、メインビジュアル制作、Webページの制作など、実際の制作をしながら実践力を身につけます。
1000名以上の卒業生がいる実績ある日本のWebデザインスクールが提供しています。


kunishii

國重侑輝 Campus inc CEO。京都でスタートアップが生まれ、育ち、旅立つ場所を作ってます。最近の興味は、Ruby・Rails / UX / React / スタートアップファイナンス /グロースハック / AWS / グラフデータベース / 自然言語処理など。 http://campus-inc.org

Next ArticleRailsのリダイレクト(redirect_to)でよく使う5つの方法