読者です 読者をやめる 読者になる 読者になる

3歩歩けば人は変わる

子どもの頃から親に叩き込まれた教えがブログのタイトルです。基本思いついたときしか書きません。

SVNしか知らないSIerプロジェクトにGit入れた時の話を簡単に

ちょっと前にやったプロジェクトで、やっとこさGitでの運用を初めました。
その時のことを軽くメモ。随時追記。



こんな感じのGit入門記事はネットを探すといっぱいあるけど、SIerに関わる意識低い系の人たちに使ってもらうには正直コレでも難しすぎる。
今回導入できたのは、プログラム開発を行う開発メンバーが比較的意識が高かったのが大きい。
僕自身諦めかけていたのだが、開発メンバーの一人が「Git使いたいんですけどー?」と言ってきたので、上に掛け合い承認してきた。

  • Gitにすることでの教育コストなどは可能な限り抑えろ、と条件付き。お陰で僕自身はGitの教育のためにほぼ動けない。チーム/拠点ごとに開発メンバーの中でGitフォロー担当を決め、この人たちだけでフォローしてもらう。3チーム×2拠点なのにGitに詳しい人は2人だけ。
  • 開発する場所は、客先プロジェクトルームと開発メンバーの社内の2拠点。客先からは80番ポートしか出られず、GitHubの利用は不可。拠点間でのファイル共有Webサービスはあり。
  • 文化的にクライアントにはTortoiseSvnを使用。VB .NET/Visual Studio 2015だったので、実データのファーストコミットはVisual Studioから。これで生成された.gitignoreを活用する。以降のコミットでのクライアント選定は個人任せ。
  • 初心者にリベースはトラブルを起こしやすいので行わない。汚れるのは受け入れる。
  • Git-Flowを参考にブランチ作成ルールを用意。master/develop/site(拠点)/member(人)。
  • developを元に拠点ごとにsite(拠点)ブランチを用意。site(拠点)からメンバー各々でmember(人)。member(人)ブランチのコミット単位は個人任せ、開発し易いように。site(拠点)ブランチへのマージルールは、SVNの時のコミットルールと同じ。
  • 拠点のGitフォロー担当が18:00頃に一日一回、拠点間ファイル共有サービスにレポジトリファイルをアップロード。チームのGitフォロー担当が、site(拠点)ブランチの内容をマージ、developに統合。それぞれの拠点のレポジトリに反映。
とまあ、Gitを使いながらも、運用はほぼSVN状態。
最初はfeatureブランチにしたかったのだが、なかなか浸透せずmemberブランチになってしまったのが実情。
SVN脳な関係者を説得するには、これぐらいしかできなかったのだが、実際に利用した開発メンバーからの声としては、

  • 自分のブランチに思いのままコミットできるので、開発し易い。
  • マージで衝突が起きた際、ちゃんと両者が残って戻せるので、前ほど怖くなくなった。
  • 拠点間のレポジトリ共有ができるのが、地味に助かる。
と、これだけでも好印象だった。
かなり意識低い系のGit運用だけど何かの参考になれば。

追記2016/07/11:
今朝の朝礼で上記内容をPowerPointでまとめ発表した。
話の始めに「Gitというツールを知っている人手を挙げて!」と声をかけたら、役に50人近くいたのだが、たったの4人。(そのうち2人は僕と一緒に上記プロジェクトに関わってた)
最初、周りに気を遣って挙げてないだけかと思ったら、マジで???な顔。
その後の発表は、「すぐ分かんなくても良いから雰囲気を感じとって!」とか「ブランチの細かいところにツッコミ出すと奥が深過ぎて挫折するから、最初は深追いするな!」とか雰囲気重視で突破。
進行役も「良いツールがあるなら、使っていこう」などとアンチにすらならない状態。 
朝っぱらから疲れました。