とりあえず流行ってるらしいGitを導入しようぜ！
ということで、Git初心者5名の開発プロジェクトに別チームが利用していたGitLabをマネして導入し、ソースの構成管理を任せることにしたのですが、「で、これどういうルールで運用するの？？」という声がすぐに上がってきたので、その際メンバーと議論したことや、調査した結果を今回はまとめておきたいと思います。
Git、難しい……。
Git Labって？
GitLab(ギットラボ)とは、ソフトウェア開発支援環境です。「GitHub」のようなサービスを社内などのクローズド環境に独自で構築できるGitリポジトリマネージャーです。Gitベースのソースコード管理機能、マージリクエスト、レビュー機能なども備えています。
Git自体もOSSですが、そのGitを使いやすくサービス化したGitHubの無料版ということでしょうか。GitHubも無料で利用できますが、公開が必須というルールがあるようです。
一方、GitLabはそういった制約がないためパブリックには非公開でグループ内開発を行うときに重宝しそうです。
我々の場合もそんな理由でGitLabを選定したと、お偉いさんに聞きました。
ちなみに、GitHubとは別ものなので若干用語が異なっていたりするようですが、そもそも僕はGitHubを利用したことがないので、よくわかりませんでした。
Gitを導入しているプロジェクトの開発
GitLabでは推奨している？開発フローがあり、それを「GitLab-Flow」と呼んでいるとのこと。
また、Gitには「Git-Flow」が、GitHubには「GitHub-Flow」というものがあるようです。
ただ、これは別にGitLabでは「GitLab-Flow」を必ず使えということではなく、プロジェクトにマッチした開発フローを選ぶなり、ローカルなルールを作るなりしてもいいそうです。
我々のプロジェクトでは、とりあえず慣れましょうということもありフローなんてまったく意識せず、各々修正が完了したタイミングでMasterブランチにコミットをしていました。
ブランチの作り方もわかってなかったんですね。
完全にSubversionのノリでやってました。
だけど、それだとどこかのタイミングで無理がやってきます。
我々の場合は、初版リリース後の本番環境でバグが発生したときでした。
そのときはすでに次のプロジェクトとして新機能の追加を行っていたので、本番で発生したバグの修正はどこでやればいいのか、修正した後どのリポジトリをリリースすればいいのか、今の最新ソースとのマージはどうすればいいのか……。
そこで、Gitを使った本来の開発フローを調査することにしたのです。
（ちなみに、そのタイミングではすぐに修正が必要だったので新機能部分に蓋をしてバグ修正版ソースをリリースするという古典的手法でなんとかしました。みんな苦笑です）
GitLab-Flowを導入してみました
色々と調べていくと上述の通り、Gitを使った開発には様々な運用ルールが世界中で浸透しており、GitLabにはGitLab-Flowがあると知りました。
プロジェクトのメンバーが全員Git初心者という大前提があるので、一番シンプルかつモダンな開発やってる！というモチベーションが保てるフローは無いものかと思案をめぐらし、最終的に僕がメンバーに提案したルールは次の通りです。
- リモートリポジトリに作るブランチは3つ（Master、Pre-Production、Production）
- 開発はMasterブランチから、Developブランチを切ってそっちでやる
- マージリクエストも使う
- ステージングにデプロイするのはPre-Productionブランチ
- 本番と同じソースはProductionブランチに置く
導入して1ヶ月後
今のところ特に問題なく運用できています。
ただ、開発者は慣れてきていいのですが管理者のみなさんには今ひとつご理解を頂いていないようで、この部分は改めて詳細な説明が必要だな～と感じてます。
Gitの解説からはじめないとダメかもわからん……。
追記：導入して２ヶ月経過
Gitを導入する前はファイルサーバにソースを置いてExcelファイルで管理していたので、いわば誰でも気軽にソースに手をいれることができる状態でした。
しかし、色々な問題があっためこの状況を改善しようとGitと導入し、確かにGitを利用するようになってから開発のスピードは上がりました。
ただディレクターやPM、お客さん側から、
「ちょっとHTMLやCSSを修正したいんだけど、Gitわからん」
「でも、ファイルは修正しておいたから、Gitに反映させておいて」
と修正したファイルがメールで送られてくるようになってしまいました。
……これは、これで面倒だなぁ～。
どうしよ。
