それまでSubversionを使っておりGit経験のないメンバーからなる少人数開発プロジェクトにおいてバージョン管理ツールをGitにしてみた顛末を日記に書きました。
http://d.hatena.ne.jp/torutk/20140119/p1
Subversion経験のある開発者(≠構成管理者)は、Subversionの経験の延長でGitを使うので、最初はトピックブランチを作らずローカルのmasterを修正・コミットしてすぐpushという作業を取り、複数開発者が同じように作業をしていると始終pushがrejectされ、pullをしてからまたpushという作業が増え、Gitは面倒だ!という認識になってしまいます。
そこで、Successful git branching modelのワークフローを参考に、変更要件ごとにフィーチャーブランチを作成し修正・コミットし、ローカルのmasterをリモートに追従させてからローカルのmasterにフィーチャーブランチをマージし、それからpushするという作業フローとしました。Subversionを使っていた開発者の大半は、個人でのブランチ・マージ作業はやってない作業なので、この作業フローを導入するととても手間に感じる作業なので、Gitは面倒という印象を持ってしまいます。
一方、Subversion経験のあるビルド・リリース担当者(≒構成管理者)は、Subversionでブランチを作成し、メインとブランチとそれぞれにコミットされた修正をマージしていく作業が結構大変であったり、開発拠点が分散(地理的分散の場合や、セキュリティ上の都合でネットワーク的に遮断、会社組織が異なる等)して一つの集中リポジトリを使えないときに、一度に大量の修正をまとめてコミットされ困ったことがある、マージ時に解消困難なコンフリクトやエラーが発生して解決に苦労をしてきており、Gitになれば嬉しいという状況です。
ところで、GitにはSubversionと連携するsvn-git機能があります。
開発の前半では開発者用にはSubversionリポジトリを立てておき、そこを「メインブランチ」としてます。
開発の後半になり、リポジトリを同じくしない開発者がソースをコミットしようとしたり、テスト等のためにリリースブランチをつくっていく段階になったときは、SubversionからGitリポジトリを作成し、Gitリポジトリ側で別な場所で作成されたソースコード群の取り込み作業をしたり、リリースブランチを作って作業するが、一方メインブランチはSubversionを継続使用します。これならば、開発者は従来どおりSubversionを使って面倒な作業をせずに済みそうです。また、Gitが使われてくるようになったらSubversionのリポジトリは廃棄しGitリポジトリに完全移行も容易にできるのではと考えます。
あくまで思いつきレベルなので、実際に効果があるかどうかは実地で試してみないと分かりませんが、試す価値はありそうと思っています。