git-flowとGitHub Flow

このエントリーをはてなブックマークに追加

git-flowとGitHub flow

複数人で Gitを利用する場合、まず決めなくていけないのはどのようなワークフローでGitを運用するかです。

その際によく利用されるのが git-flow と GitHub Flow です。

多くのプロジェクトではこれらのフローもしくは、これらのフローに独自のルールを加えたものが大半でしょう。

git-flowとは?

git-flowとは「A successful Git branching model」という記事で紹介された運用ルールで、
正確にはGit用プラグインの名称らしいですが、多くの現場ではブランチの命名規則と運用ルールとして利用されます。

以下の図がgit-flowを表す代表的なコミットグラフです。

git-flowの運用ルール

どのような命名規則と運用ルールか簡単に解説します。

初期設定

git-flowでは、まずmasterブランチからdevelopブランチをチェックアウトします。

基本的な運用フロー

開発を行う機能単位でdevelopブランチからfeature/xxxxブランチをチェックアウトして開発を進めていき、機能の開発が終了したタイミングでdevelopブランチにマージを行います。

リリースフロー

各機能の開発が終了して公開できるようになったら、developブランチの内容をreleaseブランチにマージし(初回はチェックアウト)て問題ないか確認します。
問題がある場合はreleaseブランチ内で修正をして、問題がなくなったタイミングでmasterブランチにマージを行います。

緊急のバグ修正

急な修正がある場合はmasterブランチからhotfix/xxxxブランチをチェックアウトして修正した内容を、masterブランチdevelopブランチにマージを行います。

「リリースフロー」 と 「緊急のバグ修正」 は運用ルールとしてプロジェクトごとに調整されることが多いです。(どのブランチがステージング環境に乗るかなど)

GitHub Flowとは?

GitHub Flowは「プルリクエスト」を利用してgit-flowの手間を軽減させる為の手法です。

ざっくりと解説すると、masterブランチからチェックアウトした開発用ブランチで開発を行い開発が終了したmasterブランチに対して「プルリクエスト」を送信します。

「プルリクエスト」は元々はGitHubの機能で、開発用ブランチの内容をmasterブランチに取り込むようにレビュー依頼を投げる方法です。
レビュアーに指定された方が問題ないと判断すれば、開発用ブランチの内容がmasterブランチにマージされます。

「プルリクエスト」はGitHub以外ではBitbucketやBacklog、GitLabなどのホスティングでも利用できますが、Gitそのものの機能ではなくホスティングサービスの機能に依存しますので環境によっては導入できないこともあります。

GitHub Flow でもdevelopブランチを設けたり、開発用のブランチではなくフォークした開発リポジトリで開発を行ったりとプロジェクトごとに調整されます。

git-flowとGitHub Flowどちらをつかう?

リリースフローなどはどちらを利用したとしてもプロジェクトごとに調整する必要があるでしょう。

そうなると、どちらの運用フローがプロジェクトに向いているかですが、コードレビューを行うようなプロジェクトではGitHub Flow、コードレビューを行わないようなプロジェクトではgit-flowをベースに運用フローやブランチの命名規則を考えるのがよいでしょう。

とりあえずでGitを使っているプロジェクトは、運用フローについて考えてみてはいかがでしょうか

スポンサードリンク

«EditorConfigでエディタの設定を統一する | メイン | webpackとBabelで学ぶES2015入門»

このエントリーのトラックバックURL
コメントを投稿