ブランチ運用ルールのご紹介

みなさんこんにちは

タグ打ち忘れて怒られエンジニアの金子です。

今では多くの会社がソースコードの管理にGithubを使っていると思いますが、運用ルールなどは会社によっても現場によってもまちまちだと思います。
弊社でもブランチ運用のルール化がされていない時期がありました。

大きな事故が起こる前にと、とあるエンジニアが立ち上がりルールを策定してくれたおかげで、今では定まった運用ルールというものがあります。
成果物であるソースコードの管理というのはとても大切なものなので、運用ルールをしっかりと決めて、それに沿って運用していくことが大切だと思います。

「A successful Git branching model」というあのよく見かける図と運用ルールの手順書を見ながら慎重に運用しています。

A successful Git branching modelの図

運用ルールは基本的にgit-flowに沿っています。

ブランチ運用手順

運用開始

developブランチからfeature/xxxブランチを作成します。
xxxの部分はバックログの課題番号をいれて、課題と紐づくようにしています。

弊社では課題管理にバックログを使用しています。

運用で使用しているツール紹介(1)

実装完了

feature/xxxブランチをdevelopブランチにマージします。
PullRequestを出し、ソースコードに問題なければ、feature/xxxブランチで変更した内容がdevelopブランチに取り込まれます。

developにマージされたfeatureブランチはGithub上でマージ後に表示される「Delete branch」ボタンから削除しています。

リリース準備

developブランチからreleaseブランチを作成します。

git checkout develop
git pull
git checkout -b release/v1.1.0
git push origin release/v1.1.0      ←バージョン変更を行いpush


リリース後

releaseブランチをmasterブランチにマージします。

git checkout master
git pull
git merge --no-ff release/v1.1.0
（エディタモードになるので、esc→コロン→wqで完了させる)

fast-forwardにならないよう、no-ff をつけてマージブランチを作成します。

バージョンのタグを打ちます。

git tag -a v1.1.0 -m 'release v1.1.0'
git push --tags origin master

releaseブランチをdevelopブランチにマージします。

git checkout develop
git pull
git merge --no-ff release/v1.1.0
（エディタモードになるので、esc→コロン→wqで完了させてください。)
git push origin develop


リリース後の修正

リリースしたバージョンで致命的なバグが見つかり、すぐに修正版をリリースしないといけない場合は、masterからhotfix/xxxxブランチ（例：hotfix/v1.0.1）を切ります。
hotfixは必ずmasterブランチ（現行リリースバージョン）から切り出します
。
リリース後は忘れずにhotfixブランチの変更をmasterとdevelopにマージします

masterにバージョンのタグ（例：v1.0.1）を打って完了です。

以上、ブランチ運用のご紹介でした。