みなさんこんにちは！
9月に入り、少しずつ涼しくなってきたでしょうか？
今回のブログは普段健康事業の開発保守を行っている
開発第２部保守グループが担当します。
今回はソースコード管理ツールの話をしようと思いますが、
プロジェクト開発において、成果物・・・主にソースコードやドキュメントを適切に
管理することはとても重要で、その為のツールは世の中にたくさん出回っております。
イーウェルではSubversionを使用しています。（世の中で一番有名かもしれません）
Subversionの特徴としては集中型であるということで、
開発メンバーが中央にあるリポジトリに対して、修正をどんどん反映（コミット）
していき、また他のメンバーの修正分も取り込みながら開発を進めていくスタイルが
とれます。
一方、以前勤めていた会社ではGitを使用していました。
Gitの特徴としては分散型であるということで、
開発メンバーは一度最新のソースコードを取得（Pull）すれば、自分の端末でどんどん
作り進めていける特徴があります。もちろん成果物の共有も行え、修正の差分を共有の
リポジトリにPushし、他のメンバーにPullしてもらうことで実現する事が出来ます。
リポジトリを共有する仕組みとしては、GitHubが有名です。
様々なオープンソースプロジェクトがここで公開されています。
私は、Subversionを使ったことが無かったので、今回勉強を兼ねて色々調べました。
（※参考書籍は後ろに記載）
以下GitとSubversionを対比して開発フローの説明をしたいと思います。
○Gitの開発の流れ
Git-Flowと呼ばれる開発モデルがあります。
5つのブランチがあり、それぞれ以下の役割があります。
（Gitはすべてがブランチで表されます）
・masterブランチ：現在のリリースバージョンのソースコード。Releaseブランチで
リリースされるとマージされる。
・releaseブランチ：developブランチからリリース前に作成され、リリースに向けた
微調整を行う。
・developブランチ：開発を行う為のブランチ。機能の実装やバグフィックスなどの
ブランチをここから作成し、作業を行う。
・featureブランチ：developブランチから分岐し、機能の実装を行うブランチ
・hotfixブランチ：developブランチから分岐し、バグフィックスを行うブランチ
開発者は以下のようにDevelopブランチからFeatureブランチを作り、修正を行います。
修正が完了したら、ブランチを共有リポジトリにPushします。
レビュアーが修正内容のレビューを行い、問題なければDevelopブランチにマージされます。
○Subversionの開発の流れ
Subversionではmasterブランチの事をtrunk（トランク）と呼びます。
開発者は以下のようにtrunkからbranchを作り、修正を行います。
修正が完了したら、修正branchにコミットします。
Trunkへのマージはリリース直前に問題が無いことを確認した上で行われます。
以上のように開発フローは概ね同じように思います。
ただし、感覚的にはGitの方がブランチが頻繁に作られ、頻繁にマージされていくように思います。
例えば5つの機能を開発するプロジェクトがある場合、
Gitでは５つブランチが作られ、完成するごとにDevelopブランチにマージされていきます。
Subversionでは１つブランチが作られ、機能ごとに１つコミットが作成され、最後にtrunkにマージされます。
私はバージョン管理やマージが正しく行われれば、管理ツールは何でもいいと思う派ですが、皆が使いやすく、認識を合わせ易い事が重要かなと思います。
（よく修正が無くなったとか、マージに失敗したとかありますが、ツールなので、そんなものに振り回されない事が重要）
イーウェルではSubversionを使っており、皆それでコミュニケーションをとっています。
私も早く空気を吸うように自然に使える所を目指したいです。
今回参考にした書籍は「Subversion実践入門 達人プログラマに学ぶバージョン管理 第2版」オーム社です。
以上
