git-flowについて

こんにちは。

諸々バタバタしており、更新滞っておりました…

先日、長いこと作業していた自社基幹システムのリリースが無事？終わりまして、

これからエンハンスやらなんやら頑張ってやっていかないけませんね〜

と思っています。

そこで、gitでソース管理をしているのですが今まで割と適当だったので

この機会にしっかり勉強してみようと思い、

git-flowについて勉強しました（さわりだけ）。

git-flow　とは？

gitでのソース管理をいい感じにしてくれるプラグイン？であり、考え方のことです。

ベースとなるのは

masterとdevelopと呼ばれるもので、

origin/masterは常に出荷可能な状態を保持しており、

origin/developは最新の開発ソースが反映されている、的な感じ。

（svnで言う所のtrunk)

別々にもつことで品質を担保することができ、何かあった時切り戻しが楽ですね。

で、ここからがgit独自な感じになる気がしますが

基本的に開発者は各自でブランチを切って作業します。

（サポートブランチと呼ばれるもの）

・フィーチャー

developから派生したブランチ、新機能の開発で使用。

開発終了後にdevelopにマージされる。

機能確定まで本筋を汚さずに済む。

個人毎に持つ。

・リリースブランチ

developから派生し、masterとdevelopにマージされる。

機能確定〜リリースまでの間に使われるイメージ。

・ホットフィクス

masterから派生し、masterとdevelopにマージされる。

本番障害とかが発生したときに切られる。

上記ブランチが基本となり、git-flowを使用することで

フィーチャー、リリースブランチ、ホットフィクスの開始、終了をやってくれます。

ちなみに、現在の作業で使ってるbitbucketの公式サイトでも紹介してるのですが、

https://www.atlassian.com/ja/git/workflows#!pull-request

管理方法は他にもいっぱいあります。

・中央管理型

svn管理と大差ない感じ。

trunkがmasterになるイメージで、svnからgitへ移行する際にgit導入の入り口として

おすすめしてました。煩雑なブランチ管理を一切しない。

（ちなみに、先日のリリースまではこのスタイルでやってました。）

・フィーチャーブランチ型ワークフロー

中央管理+フィーチャーブランチを使う。

・フォーク型ワークフロー

各々のローカルごとに公開リポジトリと開発用の非公開リポジトリを保持しているスタイル。開発完了したら変更ソースを管理者が公式リポジトリにコミットする。

各々でプッシュする必要がなくなるが、そもそも公式リポジトリへはプッシュできない。メインのリポジトリをフォークして開発。大規模な開発とかで使われるらしい？

・プルリクエストワークフロー

フィーチャーで開発終わったらプルリクエストをチームに投げる。

その際にメンバーがソースレビューし、問題無ければmasterへマージする

上記を踏まえ、我々は

フィーチャー型+ホットフィクスをメインにしてgitを運用する予定。

で、リリース終わったらtagを付与する感じで考えてます。

（正しい運用かは不明なので、探りさぐり…）

まだわかんないことが多いので引き続き勉強してきます。