みなさん、こんにちは。
マネーフォワードでウェブ＆サーバサイドの開発をしています黒田です。

今回のエンジニアブログは、マネーフォワードにおけるソース管理のお話しです。

ソース管理のプラットフォーム

マネーフォワードではソース管理にGitLabを利用しています。GitLabはGitHubクローンのオープンソースで、社内環境にGitLabサーバを用意することでGitHub Enterprise的に運用することができます。 GitLabを採用した理由は、主に以下の３点からです。

ソース流出の懸念から社内サーバにリポジトリは置きたかった（ここでGitHub,Bitbucketは脱落）GitHubフローライクな現代的開発フローを導入するのに適していたこと（GitHub Enterpriseとの二択となった）オープンソースで無償で利用できて、現在も活発に開発が進められていること（GitLabに決定！ ※ちなみに、GitLabにもサポート付きのEnterprise Editionもあります。）

ちなみに、GitLabを導入する前はBacklogのGitリポジトリでソース管理をしていました。しかし、エンジニアの増加に伴い、レビュー＆マージフローや情報共有面の課題が大きくなり、GitLabへ切替えました。もっと早く導入すべきだったなぁと思っています。。。

GitLabの感想

GitLabを利用しての感想は、、、、おおむね満足です。

特にレビュー＆マージフローの改善によるコード品質・情報共有のやりやすさ向上が大きいです。（私も、我が社の新卒１年生に「コードが綺麗になりましたね」とお褒めの言葉を頂きました……）
GitHub Enterpriseを利用したことがある人から言わせると、機能面や使いやすさがまだまだらしいですし、個人的にも改善して欲しい点はまだまだありますが、オープンソースで活発に開発が進められているので今後のバージョンアップに期待しています。

（個人的な）GitLabの改善要望

一応、個人的なGitLabの改善要望をあげると以下のような感じです。

diffがキレイに出ないことがある。特にside-by-side diff機能がうまくいかないことが多い本線をフォークしたリポジトリ間のマージリクエストが出せるようにしたいWiki機能でmarkdownが使えるものの、プレビュー機能が無いアイコンが怖すぎる

1は、レビュー時に問題となるので、早く改善して欲しいですね。

2は、GitHubでも確か出来なかったと思うのですが（GitHub Enterpriseは知りませんが）、エンジニア各々が本線リポジトリをフォークしたリポジトリで開発作業を進めている状況で、ある機能を分担して開発する際は、本線へのマージリクエスト前に、エンジニア同士で開発物の相互レビュー＆マージを実施することが多いので是非欲しい機能です。社内開発だとコピーライト的な問題もないですしね。

3は、GitlabのWikiはgistと同じくmarkdownで書けて、git管理されていてと大変ありがたいのですが、プレビュー機能が無いのが難点です。プレビュー機能がないと保存ボタンを押して確認するしかないため、毎回ゴミコミットが量産されてしまうので、プレビュー機能が是非欲しいです。現在は、markdownのプレビュー機能のある別サービスで記述してから、フォームにコピペし、保存するようにしています。。。

4は、このアイコン率直に怖いです。。。。。怖すぎだったので、即画像ファイルを差し替えました。

（キツネ？、エイリアン？・・・）

マネーフォワードの開発フロー

GitLabを使ったマネーフォワードの実際の開発フローですが、

本線リポジトリを作成し、git flowに則ったブランチを整備（master, release, develop, hotfix）各エンジニアが本線リポジトリをforkし、各々開発を進めていく開発物を本線リポジトリのdevelopブランチへマージリクエストを出す。レビュワーがマージリクエストをレビュー＆承認し、本線developに取り込む

といったフローになっています。
（4以降のリリースフロー詳細は省略しますが、developブランチを使ったdev確認⇛一定のタイミングでreleaseブランチへマージし、stg環境で確認⇛ masterにマージされ、リリース。といった流れになります。）

2についてですが、GitLabではバージョン5.2(最新バージョンは7.1)からfork機能が実装されたため、各エンジニアは本線をforkしたリポジトリに対してコミット＆プッシュするようにして、本線へのマージは全てマージリクエストベースにしています。
ですが、社内開発の場合は、forkする必要は無いかもしれません。ちょっと前の情報になりますが、GitHub社自体が、社内のGitHub開発ではforkは利用せず、ブランチのみで開発を進めているようですし。
ただ、個人的には、forkして作業を進めることで以下のメリットがあると思っているので、オススメしたいかなと思っています。

本線リポジトリのブランチ数が大量になることを防ぐ。気軽にプッシュできる。

1については、本線リポジトリのブランチが氾濫して嫌がる人は結構いると思います。ブランチ名の間違いとかでの事故もあり得るので、本線リポジトリはmaster, release, develop, hotfix ぐらいに整理しておきたいです。
2については、フォークしたリポジトリは基本的にエンジニア専用リポジトリなので、完璧でないコードも一旦リモートにプッシュしてという事もやりやすいです。私も、一旦プッシュしてから、rebase, amendで直したりして体裁を整えてから本線へのマージリクエストを投げるということを良くやっています。まぁ1も2も、個人の好み、開発スタイルによる差が大きいと思いますが。(^^;)

以上、マネーフォワードのソース管理についてでした。

（´-`）.｡oO　（いつかはGitHub Enterprise。。。）