前回Gitの一般的なワークフローについて説明しました。今回は弊社がGitを使って直面した問題、その改善フローについてお話ししたいと思います。
ワークフローの選択
Gitをプロジェクトのソース管理に使い始めたとき、どのワークフローにするべきか考えました。
誰でも理解できるものがいいと思いましたので、一般的によく使われるGitフロー、Githubフローの2つに絞りました。 （※前回お話ししたフロー以外にもワークフローはあります）
そして、この2つのどちらを採用しようか悩みました。
「ワークフローはプロジェクトの規模や要件に合わせて決定したほうがいい」
ということですので、弊社で実現したいことを考えました。
要件
- クライアントの了承を得てからリリースを行うのですぐにリリースはしない
- 環境が複数存在する（開発環境、クライアント確認環境、本番環境など）
上記を考慮して、Gitフローを採用しました。
ところが問題発生
順調にたくさんのブランチを作成して、多くの機能を実装しました。
先方の確認も終わって、さあリリース！
となったときに、お客様からある一言が
「一部の機能については、リリースしないでほしい」
困ったことになりました・・・
前回のGitフローをもう一度おさらいしながら説明します。
Gitフローは上図のように、機能を実装したらdevelopにマージ。また次の機能を作成するときは、そのマージしたdevelopから次の機能を作成するのです。
ということは、途中で開発した機能は、それ以降の機能には必ず含まれてしまいます！
こうなっては、途中の機能を削除するしかないですが、途中の機能を削除するとなると大変です。その機能を削除したブランチを作成してマージ・確認することになって余分に時間がかかってしまいます。
さらに後で削除したいとなるとまた大変！
解決策
この問題を解決するフローを考えました。
たとえば、3つの機能（branch A・B・C）を開発したとします。
開発環境では全ての機能（A・B・C）
本番環境では2つ（B・C）だけ実装したいとします。
その時、開発する際のフローは下記になります。
- masterからブランチを作成
- コミット
- developブランチに各ブランチをマージ
ほとんどGithubフローと同じですが、masterブランチではなく、developブランチにマージするところが肝です。
次にリリースする際のフローは下記になります。
- masterブランチからrelease Aブランチを作成
- release Aブランチにbranch Bをマージ
- release Aブランチにbranch Cをマージ
- 2つの機能を確認修正して問題なければ、masterブランチにrelease Aブランチをマージ
リリース時はどちらかというと、Gitフローに近いものになります。
こうすることで不要な機能をmasterブランチに含めずにリリースができます。
このフローの利点は複数の環境がある場合に発揮します。
その環境用のブランチを作って必要なブランチだけをマージ、その環境ブランチを反映すれば簡単に環境を複製できます。
ただ、各環境にマージする人（開発責任者）のブランチ管理が複雑になりますが、どんな環境にも耐えられるフローになったのではないかと思います。
最後に
数回に渡りバージョン管理のお話しをさせていただきました。複雑なフローは抜きにしても今までバージョン管理を敬遠していた人が自分でもできそうだと感じていただけたらうれしいです。
これでバージョン管理の話はおしまいです。