Subversion で管理してた会社のソースコード一式を、今後 Git で管理するようにやっと誘導出来た。

とはいっても、Git を採用するのが目的ではなく Github 由来の PullRequest でのコードレビューみたいな必要性があったから。それでも今どきの開発スタイルにもっていけたのはなかなか大きい。

そんな中で、今頭を悩ませているのが、Git でのリポジトリの切り方。

これまでソースコードは SubversionTrac という数年前に流行った組み合わせで管理していた。この時はソースコードのバージョン管理の必要性から結構素直に導入できたのだが、今回はシステムの変更ということでなかなかこちらの考えを100%理解してもらえない箇所も結構ある。ちなみに、社内リポジトリなので 「Github ではなく Gitlab の採用」&「メンバーがなれるまでブランチを使わない」というところで妥協してる。
内容的には Subversion から Git に変わるワークフローの変化や、PullRequest ( Gitlab 的には MergeRequest )でのレビューする仕組みなど。

まあ、そこら辺の運用の慣れとかはそのうち解消するとして、運用スタートに合わせて考えなきゃいけないのがリポジトリの切り方。最悪後から調整してもいいことではあるのだけど。

Subversion で管理してたときは、「Trunk」の下に各プログラムのフォルダをズラーッと並べていた。それを選択したのは Trac でのプロジェクトの概念があまりなかったからだと思う(一応分けることはできたけど。よく覚えてない)。 Trac 上でフォークさせて繋がりを保てるわけでもないし。
バージョン管理はしていたんだけど、それは変更履歴を記録しておくという目的のためであって、多人数でのソースコード管理という点では全然機能してなかった。その証拠に、「あのプログラムのソース今から修正するからね」「あのソース変更したからアップデートしておいて」とかがいつも聞こえてきてたから。

それが Git(Gitlab)ではフォークさせることができるので感じ的にはプログラム単位でリポジトリを切るのがいいのだろうけど、社内で使ってる自社開発のプログラムは小さいのが多いからプロジェクトがズラーッと並ぶことになる。
並ぶのは並ぶでまあ仕方がないのだけど、企業で使うプログラムは安定性が一番なので一度動き出したプログラムはあまり触る機会が無かったりする。
そんなプログラムも並ばせておくと数は増えていく一方になるので、それはそれで見通しが悪い。

これがベンダーさん側のソース管理であれば、XXXX株式会社向けという単位でリポジトリを切ればちょうどいいんだろうけど、自社開発だとそういうわけかたも出来ないし。

そこで考えたのが、 VisualStudio, Web, Batch, Oracle といった単位でのリポジトリの切り方。
会社単位で切るように部門ごとに切るということも考えれたけど、部門を超えて使う時もあるから言語+機能別っていうのが適当な感じでちょうどいいかなと。

まだ運用開始もしてないのでこれがいいのか悪いのかも分からないんだけど、そんなに悪くはないんじゃないかとは思ってる。

ところで、他の会社ではどうやって管理してるんだろう?