第3章 Github Flow/Git-Flowを使った運用

Github Flowの概要

2016年9月1日

Github Flowの概要

Github FlowはGitのブランチ管理をルール化したシンプルなワークフローで、短いスパンでデプロイをするようなサイトに最適です。既発のGit Flowと違ってインストールの必要がなく、ルールも簡単なため導入コストが低く抑えられます。

Github Flowは必須ブランチがmaster以外になく、そのほとんどがmasterから作業ブランチを作成、masterに作業ブランチをマージといったシンプルな流れになります。
確認用ブランチが存在しないためシンプルなブランチ管理になっており、デプロイや修正が素早く手軽に行うことができます。

作業用ブランチを作成する際は、短いスパンでデプロイすることを目指し、最小限の作業範囲で作成します。
作業範囲を狭めることにより、大きなバグの発生を抑えられるというメリットもあります。

Github Flowのルールは以下の通りです。

  • masterブランチは、常時デプロイ可能な状態を保つ
  • 全てのブランチはmasterブランチから作成する
  • 作業内容が分かるようなブランチ名をつける
  • 作業中のブランチは定期的にプッシュする
  • Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする
  • マージされたmasterブランチのコードはすぐにデプロイする
  • デプロイ後は速やかに作業していたブランチを削除する

シンプルなフローですが、Githubでも採用されているように、数十人規模のチームでも機能している実績があります。

Github Flowのルール

masterブランチは、常時デプロイ可能な状態を保つ
全てのブランチはmasterブランチから作成する

masterブランチは常にデプロイ可能な状態が保障されているので、安心してそこから新しいブランチを作成することができます。

作業内容が分かるようなブランチ名をつける

GitHubでは、user-content-cache-key、submodules-init-task、redis2-transitionといったブランチ名を使っているそうです。
どのような目的で作成されたブランチなのかブランチ名から推測できるので、複数のブランチを管理する際に便利です。
ブランチの種類を改修・機能追加とバグフィックスの2つに分けて、下記のような命名法を決めても良いでしょう。

  • 機能追加:feature-機能を表す名称
     例) feature-user-notice
  • バグフィックス:fix-修正を表す名称
     例) fix-login-validation

また、このルールの利点として、fetchすると他の開発者が作業しているトピックを知ることができる、という点も挙げられます。

作業中のブランチは定期的にプッシュする

作業中のブランチを定期的にpushすると、その時点の最新の作業がリモートにバックアップされます。この利点以外にも、他開発者が git getch すれば自分以外の課題がどのように進んでいるのかを確認できます。

Githubのプルリクエストを利用してレビューを行なってから、masterブランチにマージする

Githubにはプルリクエストというコードレビューの仕組みがあります。
他の開発者にプルリクエストを送り、確認や助言をしてもらいます。これで問題なければ、masterブランチにマージします。

マージされたmasterブランチのコードはすぐにデプロイする

masterブランチにマージした後は、即時でデプロイします。

デプロイ後は速やかに作業していたブランチを削除する

作業が終ったブランチがいつまでも残らないように、ローカル、リモートでデプロイしたブランチを削除します。

HTMLコーディングがメインのブランチ管理

Github Flowは十分シンプルですが、静的ページのみのサイトや、1人で運用しているサイトではもう少しスリムにできる猶予があります。
たとえば、静的ページのみの小規模なサイトの場合、HTMLやCSSを他人にレビューしてもらう利点はそれほどありません。
コードのレビューよりも、ブラウザでどのように表示されるかの方が重要だからです。

Github Flowからプルリクエストを省略するとその思想からはだいぶ離れてしまいますが、0からルールを作成するよりも、すでによく知られているGithub Flowをカスタマイズするほうが楽です。
ここでは1人、もしくは少人数で、コードビューがそれほど重要ではないケースを想定した作業の流れを紹介します。

作業環境
本番環境のディレクトリ:
/var/www/example.com
開発環境のディレクトリ:
/var/www/dev.example.com
リモート:
Github

開発スタート

1) 開発用ディレクトリに移動
cd /var/www/dev.example.com
2) 開発用ブランチを作成

masterブランチに切り替えて最新の状態にします。

git checkout master
git pull origin master

masterブランチから新しいブランチを作成します。

git checkout -b [新しく作るブランチ名]

開発期間

1) 定期的に開発用ブランチをmasterにプッシュ

開発用ディレクトリに移動して、定期的に開発用ブランチをmasterにプッシュします。

cd /var/www/dev.example.com
git pull origin [新しく作るブランチ名]
2) 変更をコミット

まず、更新、追加ファイルなどを確認します。

git status

インデックスに未登録のファイルがあると下記のようなメッセージが表示されます。

Untracked files:
(use "git add ..." to include in what will be committed)
ファイル名

この場合は下記コマンドで未登録のファイルをインデックスに追加します。

git add [ファイル名]

下記コマンドで全ての未登録ファイルをインデックスに追加できます。

git add .

問題なければ、コミットメッセージをつけてコミットします。

git commit -am "****"

デプロイ

1) 開発用環境でmasterブランチにマージしてプッシュ

開発用ディレクトリに移動して、masterブランチに切り替えます。

cd /var/www/dev.example.com
git checkout master

開発用ブランチをmasterブランチマージして、リモートにプッシュします。

git merge --no-ff [ブランチ名]
git push origin [ブランチ名]
2) リリースする
本番用ディレクトリに移動してプルします。
cd /var/www/example.com
git pull
3) コミットの確認
git log
4) リリースしたブランチの削除

開発用ディレクトリに移動してローカルブランチを削除します。

cd /var/www/example.com
git branch -d [ブランチ名]

リモートブランチを削除します。

git push origin :[ブランチ名]

Comment

コメントを残す

メールアドレスが公開されることはありません。

リズムファクトリーはホームページの制作会社です。
ホームページ制作に関するご要望・ご相談はこちらからどうぞ。