私の勤めている会社では、GitHub運用にgit-flow。Issueドリブン開発を採用しています。 gitは開発する上で、とても重要な概念なので自分自身の理解と整理のために、git-flow、Issueドリブン、ブランチの命名規則などについてまとめてみました。

git-flow

正確にいうと「A successful Git branching model」をサポートするためのツールの名称らしいです。

git-flowでは、下記の５つのブランチを利用します。

masterブランチ

リリースしたソースコードを管理するためのブランチ。

developブランチ

開発を行うためのブランチ。開発者は、主にこのブランチ上で作業を行う。 featureブランチなど、他のブランチで行った作業は、ここにマージされる。

featureブランチ

主要な機能を実装するためのブランチ。機能の実装やバグフィックスなど、タスクごとにdevelopブランチより featureブランチを作成し、作業を行う。

releaseブランチ

リリースの準備を行うためのブランチ。プロダクトをリリースする前に、このブランチをdevelopブランチより作成し、微調整を行う。 releaseブランチで作業した内容を、同時にdevelopブランチにもマージし、最新の開発版を反映させる。 releaseブランチを作成することで、リリース準備と次のバージョンに向けた開発のコードを分けることができる。

hotfixesブランチ

リリースされたソフトウェアに緊急の修正を行うためのブランチ。

master：　本番、releaseからマージ
develop:　開発環境
release:　ステージング環境
feature:　各機能開発環境　developからブランチを切る
hotfixes:　バグ対応

Issueドリブン開発・命名規則

Issueドリブン開発とは、実装における課題をタスクとして管理・運用する開発手法になります。新規機能の追加やバグ修正などをIssueとして立てて、それを解決するためのブランチを切り、コミットやPRでIssueを参照しながら開発を進めるという流れになります。

Issueドリブン開発の流れ

1.　GitHub上で、課題（タスク）のIssueを立てる。

2.　Issue番号が発行されるので、Issue番号を付与したブランチを作成する。

例）feature/#1-add-login

3.　Issueの課題（タスク）に沿った、開発を行う。

4.　開発が完了したら、developブランチにコミットする。PRのコメントにclose #1と記述すると、マージ後にIssueがクローズされます。

コミットメッセージ

例）[fix]refs #1 add-login

fix：バグ修正
add：新規（ファイル）機能追加
update：機能修正（バグではない）
clean：整理（リファクタリング等）
remove：削除（ファイル）