gitflow

gitを使った開発フローは、プロジェクトによっては多少違いはあるものの、基本的にはmasterブランチ、developブランチ、featureブランチ、releaseブランチ、hotfixブランチを主なブランチとして開発を進めていきます。

それぞれのブランチの役割について理解し、実践の場でいつもで使えるぜ、と思っていてもいざ実際に運用してみると意外にあれっ?て思うことが多かったので、これを機にわかったつもりからわかるへ昇華させるべくまとめてみたいと思います。

はじめに

これから説明するのはgitを使用した一般的な開発モデルであるgit-flowモデルについてです。
基本的にこのモデルに従うと現在のソフトウェア開発のおいては効果的な開発が出来ると言われています。
それぞれのブランチの役割は以下のとおりです。

メインブランチ

メインブランチとはその名のとおり、メインのブランチとして運用していくブランチ。
これらのブランチはプロジェクトを通して削除されることなく、成長させていくべきブランチである。
メインブランチとして以下の2種類がある。

[masterブランチ]
常に出荷可能な状態を保っておくべきブランチ。

[developブランチ]
次のリリースの向けて最新の開発状況を反映しておくブランチ。
ソースコードが安定し、次のリリースに向けて実運用に耐えられる品質を確保できた場合、masterブランチにマージする。

サポートブランチ

サポートブランチとは、メインブランチとは異なりプロジェクトで起こりうるざまざまな問題に対応するためのブランチ。
developブランチにマージされるなどしてその役目を終えると基本的には削除する。
サポートブランチとして以下の3種類がある。

[featureブランチ]
いつかリリースされるであろう機能を実装するためのブランチ。
developブランチ(最新を進んでいるのがdevelopブランチだから)からcheckoutし、必要な状況でdevelopブランチにマージされる。

[releaseブランチ]
製品版リリースのための最後の準備をするためのブランチ。例えば小さなバグを修正などをし品質を高める。新たな機能の追加は行わない。
developブランチからcheckoutし、最終的にはmasterブランチにマージする。
masterブランチにマージした後に、developブランチにもマージする。

[hotfixブランチ]
製品版(master)の予期せぬ不具合などに対応するためのブランチ。
featureブランチとはその修正が計画されているか否かという点で異なる。
masterブランチからcheckoutされ、masterブランチにマージされる。
また、以後のリリースでも必要なため、developブランチにもマージする。

マージ系コマンド

続いてgitのマージ系のコマンドについて説明します。
gitの開発のモデルでは上のように複数のブランチで運用するため、「あるブランチで行った変更内容を他のブランチへ反映する」機会が多いです。
そのためマージ系のコマンドは運用していく上で押さえておくべき重要なコマンドのひとつになります。

[mergeコマンド]
ブランチを選択して、そのブランチで行ったコミットを取り込むコマンド。
featureブランチで行った内容を取り込みたい場合は
git merge feature
のように使用する。

このコマンドによるマージには以下の2種類のマージがある。

・fast-forward
・no-fast-forward

例えば、developブランチからcheckoutしたfeatureブランチで開発を進め(コミットをした)、developブランチへマージする場合を考える。
①checkoutしてからマージするまでの間に、他の開発者によってdevelopブランチへコミットが行われなかった場合
featureのコミット履歴の中に、developのコミット履歴が全て含まれている(developが分岐していない)ため、マージの結果は単純にdevelopブランチのheadが移動するだけ完了する。
このようなマージを「fast-forward」と呼ぶ。

②checkoutしてからマージするまでの間に、他の開発者によってdevelopブランチへコミットが行われた場合
featureのコミット履歴の中に含まれないコミットがdevelopに含まれている(featureとdevelopが分岐してしまっている)ので、上のように単にheadが移動するだけでは対応できない。二つにブランチの変更内容を一つにまとめる対応が必要になる。
このようなマージを「no-fast-forward」と呼ぶ。

続いて、よく聞くmergeコマンドのオプションの–ffと–no-ffについて
これらのオプションの違いはマージの際にコミットログを作るか否かという点。

gitのデフォルト設定では–ffオプションとして実行され、この設定の場合、マージの種類がno-fast-forwardだった場合はマージコミットを作るが、fast-forwardだった場合はマージコミットは作らない。
git merge feature
(–ffはつけなくて良い)

–no-ffの設定でマージを行った場合、no-fast-forwardだろうと、fast-forwardだろうとコミットログを作る。
git merge –no-ff feature

これらのようにマージコミットを作るか作らないかが運用にどのように影響を及ぼすかというと、
例えばrevertするときの利便性として、fast-forwardの場合でも、–no-ffオプションでマージコミットを残しておくことで、1発で1機能分の修正(fetatureで行った修正)を打ち消せる。
その他には他のブランチからマージされた、という事実を履歴に残したいかどうかで使い分けるといい。

・・・ちなみにrevertとは対象のコミットを相殺するようなコミットを自動的に作成するためのコマンド。
例えば、あるAファイルに
aaaaaaaa
という1行を追加してコミットした場合(コミットid:xxxxxxxx)

git revert xxxxxxxx
コマンドによりAファイルに追加した
aaaaaaaa
を削除するコミットを自動的に作るコマンド。

何が嬉しいかというと不要になったコミットを簡単に安全に取り消す(コミットログにも残しながら)ことができること。
例えば、ある期間だけ表示していた画像を期間が過ぎたので削除したい、みたいなことを
revertコマンド一発で完了させることができる。
ABテストとかする場合にはよく使われるのかな。わからんけど。

[cherry-pick]
特定のコミットによる変更を他のブランチに反映させるコマンド。
特定のブランチの変更(複数コミットあれば全て)を全て反映させるmergeに対して、1コミットだけを選択して反映するという点で異なる。
実運用では、featureブランチで開発している中で既存のバグを発見しその修正を含め新規機能を作ったけど、
そのバグは実は緊急を伴うものだったのでその修正分だけすぐにmasterに反映したい、っていう状況で使える。
例えば、featureブランチのそのコミットidがxxxxxだった場合
git cherry-pick xxxxx
コマンドによりそのコミットのみ取り込める。

参考文献

http://keijinsonyaban.blogspot.jp/2010/10/a-successful-git-branching-model.html
http://d.hatena.ne.jp/sinsoku/20111025/1319497900

スポンサーリンク
スポンサーリンク
スポンサーリンク

シェアする

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

フォローする

スポンサーリンク
スポンサーリンク