田中(邦)です。

前回はtowerを利用してSubversionのリポジトリをGithubに移行する手順について書きました。

そもそも上記の記事を書くきっかけになったのは、弊社の社内開発改善ミーティングで

「社内開発用のリポジトリをそろそろSubversionからgitに切り替えようぜ」

という話になった時

「移行時にスクリーンショット取ってれば後でブログに書けるんじゃね?」

という意見が出たのが発端です。

そんなわけでリポジトリの移行は無事終わったのですが、まだまだやることはたくさんあります。

git,Githubを使ったことがないメンバーに対して勉強会を開いたり、今までJenkinsを使っていなかったのでJenkinsを導入したり、あとはVagrantやらAnsibleを導入したいなぁ・・とか。

今回はgitでの開発に切り替えるにあたり、どのようなブランチモデルが弊社の社内開発に最適か、ということについて考えてみます。

gitの代表的なブランチモデル

gitの代表的なブランチモデルといえば、おそらくgit-flowGithub Flowの2つではないかと思います。

リンク先のサイトを読んでいただければ分かると思うのですが、git-flowは比較的カッチリしたブランチモデルで、多少複雑です。

それに対してGithub Flowのほうは単純な構造で1日に何回もリリースするようなプロダクトに向いています。

Pull Requestsを利用したコードレビューが開発のフローに組み込まれているのも特徴です。

キャスレーの社内開発に向いているのはどっち?

弊社の社内開発の現状は以下の通りです。

  • 社内開発に携わっているエンジニアは15人ほど
  • 一部のメンバーを除き、大半のメンバーがgitを利用した開発経験がない
  • 中にはスキルレベル的に他のエンジニアのフォローが必要なメンバーもいる
  • 1日に何回もリリースしたりはしない

これらを踏まえて考えると、リリースの頻度はそれほど多くもないし、git-flowは多少複雑なブランチモデルではあるけれど勉強会とかでサポートしつつGUIのクライアント使って貰えればそれほどgitの習得にも時間がかからないだろうし、業務系のプロダクトだからカッチリした構成のほうがいいだろうと思って単純にgit-flowが良いかなーと思ったんですが、やはりGithub Flowに含まれているPull Requestsを利用したコードレビューは魅力的です。

熟練したエンジニアがいくら忙しくても、コードレビューがワークフローに入っていれば必ずPull Requestsをメインブランチにマージする時にコードをチェックすることになりますし、レビューされる側も必ずコードが見られるという緊張感が生まれて良いんじゃないかと思います。

というわけで基本的にはgit-flowを使いつつもPull Requestsを利用したコードレビューの仕組みが欲しい。

じゃあどすうるか?

基本はgit-flowを踏襲するが、developブランチ上で開発は行わずdevelopブランチから作成したフィーチャブランチ上で開発する。

開発が終わったフィーチャブランチをdevelopブランチにマージしたい時にPull Requestsを投げて、責任者がコードレビューを行い、developブランチにマージする。

という感じでいこうかなぁと思っています。

Pull Requestについて

いきなりPull Request使えとか言われても使ったことないしわからないよ!

という方もいらっしゃると思いますので少し解説します。

Pull Requestというのは簡単に言うと

A さん: 「俺こんな機能作ったんだけど、問題なさそうだったらそっちのブランチにマージしてよ!」

B さん: 「OK! コードレビューしてから問題なさそうだったらマージしとくよ。」

を実現するための仕組みです。

図で表すとこんな感じでしょうか。

Pull Request

developブランチの責任者であるBさんが、Aさんが開発したsome_featureブランチをコードレビューし、Aさんから送信されたPull Requestを受け入れることで初めてdevelopブランチにAさんの変更が反映されます。

それでは実際にGithub上でどのように操作するか見ていきましょう。

まだマージされていないブランチがあると、Pull Requestできるよというボタンが現れますのでそのボタンを選択します。

pullrequest1

次にどのブランチに対してPull Requestを投げるか聞かれますので、対象のブランチを選んでSend Pull Requestボタンを押します。

この時、Pull Requestに関する説明を記述することもできます。

pullrequest2

これでPull Requestが送信されましたので、今度はBさんがPull Requestを確認しにいきます。

pullrequest3

Pull Requestsタブを確認すると、1件Pull Requestが来ていますね。

このPull Requestを選択します。

すると、どのようなコミットが含まれるPull Requestなのかが表示されますので、問題なければMerge Pull Requestボタンを選択します。

これでdevelop_some_featureブランチがdevelopブランチにマージされました。

問題があった場合は、相手とディスカッションすることもできます。ディスカッションの結果、不要な修正であればリジェクトすることもできます。

pullrequest4

マージされたブランチは残していても邪魔なので、その場で削除することができます。

pullrequest5

以上がPull Requestの送信と受け入れの流れになります。

実際に運用が始まったら、このブランチモデルを採用して良かった点や問題があった点などをご報告したいと思います。