Git / GitFlowをチームに導入してよかったこと・よくなかったこと

git

チーム向けにgit-flowの勉強会をやってみた。

ちょうどいい機会なので、それまで使っていたCVSと比較しながら、

チームにGit/GitFlowを導入してよかったこと、よくなかったことを書いてみる。

状況

うちのチームは1年前くらいにそれまで使っていたCVSを脱して、Gitに全てのリポジトリを移した。

皆にGitにしたいって強いモチベーションがあったわけではなく、CVSが近いうち使えなくなるからということで、半ば強制的に移行した。

長期にわたるリリースが多いので、GitFlowブランチモデルを使ってる。

Git / GitFlowをチームに導入してよかったこと

Pull Requestでレビューがすごく楽

CVS時代はReviewBoardというレビューツールを使ってた。

ReviewBoardも左右のファイルのdiffを見てレビュー出来る点で結構いいツールだったけど、

diffを見るためには自分で変更した後diffファイル作って、それをアップロードして。。。となかなか手間がかかった。

さらに変更ファイル数が多いとアップロードしきれず、わざわざ一つの変更を複数のレビューに分けるとか変な工夫を強いられていた。

　

Gitで(というかGitの管理ツールで)Pull Requestを使うと、commitしたら勝手に変更がレビューに反映されるので、diffファイル作る手間がない。

また、Pull Reqest上にcommit logが出るので、誰がどの変更をしてどの状態になったかすぐわかる。

Pull Requestはこれなかったらもう開発できないレベルになったと思う。

Repositoryごとにバージョン管理を行うからマージ漏れが減る

CVSはファイルごとにcommitを行い、ファイルごとにバージョンを持っていたので、

変更履歴が一覧で見れないし、全部のファイルがブランチからHEADにマージされたか確認するのもだいぶ苦労してた。

　

Gitはリポジトリごとにバージョン管理しているので、そのリポジトリに対するコミットログが一目でわかるし、

ブランチをマージする際もそこまで負担がない。

今のアクティブブランチがすぐ見れる

CVS時代、何年も積み重なったブランチとタグがあり、

現在のアクティブブランチを確認するのは後述するExcelブランチ絵を見るしか方法がなかった。

さらに、ブランチを切るときは全体にメールするっていう謎の運用があった。

　

GitHubなどの管理システムでは、現在切られているブランチをすぐ確認することができる。

リリースが終わったブランチは削除するという運用にすれば、

現在切られているブランチは全てアクティブブランチということになる。(ここの運用は自分たちでやる必要があるけれど。)

今のアクティブブランチさえわかれば、今どんなプロジェクトが進んでいるのかだいたいわかるし

ブランチを切ったことを全体にメールするなんてことはもちろん必要なくなった。

コミットグラフ(ブランチ絵)*1の管理をしなくて良くなった

CVS時代は、それはそれは長く成長したExcelファイルを相手に、コミットグラフを自分たちで描いていた。

Excelなので、誰かが編集中だから今は書けないとか、共有ファイルサーバの容量がいっぱいで今は保存できないとか

辛く厳しい戦いを強いられながら、私達はExcelファイルを編集していた。

　

まず、Gitは前述したようにアクティブブランチが常に見れる状態なので、ブランチ絵をそもそもそんなに厳重に管理しなくても良くなった。

さらにブランチ絵を見たい場合は、うちのチームは余りまだ活用しきれてないんだけど、SourceTreeやgitkなどのツールを使うと

特に何もせずとも自分の作業のブランチ絵が見れる。

f:id:Sato_4tree:20140714234112p:plain

releaseブランチの時点で1度マージできる

これはGitFlowについて。

CVS時代、ブランチをHEADにマージするとなるとそれはそれは一大事だった。

リリース直前に他のマージされたブランチの差分を見ながらデグレって無いか確認しつつ、

半日くらいかけてCVSのいろんなオプションを駆使してdiff確認してマージを行っていた。

　

git-flowを使うとreleaseの時点で他のブランチがdevelopに入れた変更をマージすることができる。

releaseブランチでQAやリハーサル環境でのテストをやるようにすれば

他のブランチの変更が入った状態でテストを行うことが出来るので、デグレなどのリスクが減る。

さらにリリース直前じゃなくQAの前段階で1回マージできる安心感もある。何かバグがあればreleaseで直せるので。

releaseやhotfixからタグを自動で付けることができる

これもGitFlow.

CVS時代、（これはうち特有だけど）マージ時などににまたこれはこれは色んなタグを付与していた。

ブランチ切った時点のタグ、HEADマージ前タグ、HEADマージ後タグ、ブランチ側マージ前タグ、リリースタグ...etc

CVSの時は1ファイルだけHEADを直更新するとか、ブランチからブランチへマージ、みたいなことをちょくちょくやっていたので

実際これらのタグはdiffなどを確認するとき必要であった。

git-flowコマンドを使うと、 releaseやhotfixを切るときにタグ番号を指定することになり、

さらにreleaseやhotfix→masterへマージするときに自動的にタグ番号が追加される。

masterへの更新はこの2ブランチからのマージでしか起こらないので、タグの管理もシンプルなものになる。

実際CVS時代あんなに使っていたタグも、GitFlowに従うようにしたらこのシンプルなタグ番号のみで十分事足りるようになった。

困ったらググれば色々でてくる

CVSはもうかなり昔のサービスなので、ググってもなかなか情報がありません。

Gitは困ったらすぐ情報が出てくる出てくる!!

git add, commit, pushを取り消す方法やら、git-flowの使い方やら、困ったらgoogle先生に聞けば大抵のことは教えてくれます。

Git / GitFlowをチームに導入してよくなかったこと

学習コストがかかる

これはGitに限らずなんにでも言えることだけど、学習コストはそれなりにかかる。CVSとはかなり異なるコマンド使うのでなおさら。

さらにGitFlowの話になると複雑になって、「こんな複雑なのすぐ廃れるだろ」とか「なんでこんなことやるんだ」とか色々言われたりする。

だけど、そこでくじけずリポジトリ移しちゃえば強制的にGit使うようになるし、その後色々楽になるはずなので、皆様頑張って導入していただきたいですｍｍ

GitFlowの流れが複雑でマージミスがよく起こる

ほんとこれに限るなと。

GitFlowはmaster, develop, feature, release, hotfixという5種類のブランチを使いながら開発していくやり方であり、

どこからどこへマージするべき、というのも明確に上の図のように定められているのですが、これを覚えるのはなかなか大変。

それでもgit-flowコマンドを使っていればミスが起こることはほぼないのですが、全員には浸透しきっていないようで

間違ってまだリリースするべきでない内容がfeature→masterにマージされるみたいなことが何度か起こった。

このへんは気づかないと大惨事だし、気づいてgit resetやgit push -fなどを駆使して修正するのは特定の人だけになるので

こういうGitトラブルシューティングに工数を割かれている部分がある。

（Gitトラブルシューティング力はもっといろんな人に広めないといけない。。。）

GitFlowの流れが複雑で無理やりマージもよく起こる

CVSの時は、1行だけ設定ファイルを変えたいときなど、1ファイルだけcheckoutして更新してHEADに直commitみたいなことができていたのだけど

GitFlowではmasterの直更新は不可なので、ほんの少しの更新でもhotfixブランチを切ってもらってマージすることになる。

それがめんどくさい、と感じるのもまあ当然ではあるので、

無理やりmasterだけ更新して、その内容をpull request使ってdevelop->masterにマージされたりみたいなこともちょくちょく起こる。

　

この両問題は、GitFlowの使い方を熟知してもらうこと、使うメリットをわかってもらうことが重要だと痛感。

まとめ

以上、Git/GitFlowをチームに導入してよかったこと、よくなかったことでした。

もちろん総合的に見れば良いこと尽くしですが、ちょっと難しいところもあったよというところで。

これからGit、GitFlow使い始める方はご参考にしていただけたらと思います。

*1:そういえばうちはコミットグラフをブランチ絵って言うのですが、社内用語だろうか。。。？