出会い
2011年に入社以来、2017年に今の案件をやるまでSubversion一筋、現在、Git（GitHub）を使用している。
Subversionについては、最初から当たり前にあったものなので出会いの感想も特にないが、
Gitについては、リモートリポジトリとローカルリポジトリの仕組みが自分にとっては新しく印象的だったように思う。
Subversionとは
Subversion（Apache Subversion）は、さまざまなソフトウェアの開発現場において広く使われているソースコード管理システムです。
...中略...
Subversionではソースコードやそこに加えられた変更点などの履歴はすべて中央リポジトリに記録され、各開発者はネットワーク経由で中央リポジトリにアクセスすることでソースコードを取り出したり、変更点を記録するという中央集権型のバージョン管理機能を備えています。
Subversion（svn）によるソフトウェア開発を始めよう
中央リポジトリなので開発者にとっては、ソースコードは以下の３つの状態が存在する。
- 自分のPCにあってまだコミットされておらず、バージョン管理もされていないソースコード。
- バージョン管理はされているが、自分のPCにあってまだ変更内容がコミットされていないソースコード。
- コミット済みでリポジトリ上にもあるバージョン管理されているソースコード。
コミットされていないソースコードは、万が一HDDやSSDが壊れたりすれば、PC内にあるその他のデータと一緒に消える。
なので、こまめにコミットすることが多かったし、PJとしても推奨していたように思う。
ただ、たまにビルドの通らない状態でコミットするメンバーが（自分も含め）いて、それを取り込むとPJ全体がザワザワすることになる。
気軽にコミットしていると弊害もあるが、とはいえ、コミットしていないと他のメンバーと盛大にコンフリクトする範囲や可能性も広がっていく。
ここらへん技術的にどうするかというよりは、開発する機能やクラスの単位を予め、計画してコントロールしていた。
Gitとは
Git は、元々 Linus Torvalds によって 2005 年に作られた、無料でオープンソースのバージョン管理システムです。他の SVN や CVSといった中央バージョン管理システムと違って、Git は分散型で、すべての開発者がローカル環境で彼らのコードのリポジトリの完全な履歴を持っています。
Git を学ぶ - Git のチュートリアル、ワークフローおよびコマンド | アトラシアン
分散リポジトリなので開発者にとっては、ソースコードは以下の４つの状態が存在する。
- 自分のPCにあってまだコミットされておらず、バージョン管理もされていないソースコード。
- バージョン管理はされているが、自分のPCにあってまだ変更内容がコミットされていないソースコード。
- コミット済みでローカルリポジトリ上にだけあるバージョン管理されているソースコード。
- コミット済みでローカルリポジトリだけでなく、リモートリポジトリにもあるバージョン管理されているソースコード。
結局、万が一HDDやSSDが壊れたりすれば、PC内にあるその他のデータとローカルリポジトリ共々、一緒に消えるのは変わらない。
ただ、Subversionに比べれば、ローカルリポジトリの存在があるので、気軽にコミットしやすい。
どんなコードを書くかまだ定まってない試行錯誤の段階では、書いて、コミットして、リファクタして、コミットしての繰り返しに心理的な抵抗がSubversionと比較してかなり低い。
うっかりビルドの通らない状態でコミットしても、他のメンバーにご迷惑をかける前に気づける可能性が高い。
リモートリポジトリにコミットしていないと他のメンバーと盛大にコンフリクトする範囲や可能性も広がっていくのは、
Subversionと同じでここらへん技術的にどうするかというよりは、やっぱり開発する機能やクラスの単位を予め、計画してコントロールすることになる。
振り返ってみて
Gitの方がSubversionより後発だから良いし、メリットも感じられるはずだ。
そう思っているかというと個人的にはそうではない。
中央リポジトリと分散リポジトリという考え方の違いは、開発のスタイルによってよりメリットを感じられる場合もあるし、
逆に「SubversionからGitに移行したけど、あんまりメリットを感じられない。。」というケースもある。
実際、身近な範囲でもそんな話は聞く。
どちらかというとSIだと
- ウォーターフォール（要件定義、設計、実装、テスト）のフェーズを切って開発する。
- 長期間かけて、複数の機能からなる１つのシステムを参画メンバー全員で開発する。
- リリースは、複数の機能を束ねた大きな塊でまとめてやる。
ことが多いので、設計段階でクラス設計してしまって、影響範囲に応じてメンバーに対してタスク割当てを行うと、
中央リポジトリでもデメリットをあんまり感じなかったりする。
気軽にコミットしていても、担当タスクが他のメンバーとの影響が考慮済みであれば、
問題にならなかったりする。
PM（Project Manager）からすると分割リリースでもしない限り、今のPJメンバーで作っているものは一緒のタイミングでリリースするので、
中央リポジトリにどんどんコミットされている方が進捗も分かるし、状況が把握しやすい面もある。
逆にサービス開発だと
- アジャイルにウォーターフォールほど明確なフェーズ分けはなく開発する。
- 短期間で、個別の要件、機能単位で個人、チームやユニットごとに参画メンバーが開発する。
- リリースは、個別の機能ごとに小さな単位でやる。
ことが今の案件もそうだが多いかと思う。
これだと設計段階でクラス設計してしまって、影響範囲に応じてメンバーに対してタスク割当てを行うのは、開発スタイルに合わない。
個々のメンバーやチームの担当タスクの影響は、コントロールされるべきだと思うけど、
リリースタイミングも状況によって前後するし、より柔軟性がある仕組みにしないとそこがボトルネックになると思っている。
その点、分散リポジトリでやる方が向いているし、メリットもより感じられるのだと思う。