svnを使っている作業場でgitを普及させるためにやったこと

公開日: : 最終更新日:2015/11/25 IT全般

今回は、ある作業場でgitを普及させたい!という思いから、私が個人的に調査したこと、伝えたことを紹介します。

同じく、svnからgitに移行したいと考えている人は、チームの人を説得する材料の一つとして参考にしていただければ幸いです!

以下、聞かれそうなことをまとめました。

※イメージで話しているので、厳密には用語が違ったりします。

(gitのpushのことも、コミットと呼んでいたり)

gitって何?svnとの違いは?

gitもsvnと同じく、バージョン管理ツールです。

よく言われることで、svnは集中管理でgitは分散管理だとか、gitならオフライン環境でも個別にバージョン管理できるだとか、そんなことを言われますが、使ったことのない人にそういう説明しても大体伝わりません。

大切なのは、

「同じバージョン管理ツールだが、gitのほうが汎用性があり、svnで起こる色々なトラブルを解決できる」

ということだけです。

例えばどういう時にgitは役立つのか?

私の体験談からいくつか紹介します。

コミットミスで開発者全滅、が無くなった

昔svnを使ってとある開発を行っていたとき、

毎日のように起きていたのが、

「コミットミスにより、開発者すべての環境が壊れてしまう」

ということでした。

svnから最新ソースコードを取ってきたら、いきなりビルドエラー!

そんな悲しい経験をされた方、多いと思います。

これ、結構でかいんですよね、コストが。

これは趣味の話だったのでいいんですけど、

もし仕事で50人規模とかでやってる開発だとしたら、全員の手が0.5~1時間止まるって考えたら

それだけで25~50人時です。

開発規模が大きくなればなるほどダメージが大きいです。

gitでは、このようなことは起こりません。(※運用をしっかりやれば)

各作業者が自分用のブランチ(ワークスペース)を作ってから作業するため、

svnのように自分のコミットが他の開発者にいきなり影響することはまずありません。

ビルドエラーが起きても、コミット漏れがあっても、

あくまで影響を受けるのは自分のみです。

周辺ツールが強力すぎる

svnと違ってgitには、

GitHubや、GitHubクローン(GitLab,GitBucketなど)と呼ばれる

協力なサポートツールがあることが大きいです。

svnの場合、TortoiseSVNを使って作業することが大半だと思いますが、

GitHub等の何が強力かって、

「Web上でなんでもできる」これに尽きます。

  • コミット内容、差分の確認
  • レビュー(コミット内容に行単位でコメントを記入できます)
  • ヒストリーの確認
  • ファイルの編集、更新
  • バグ情報の管理(Issuesと呼ばれています)

などなど、挙げたらキリがありません。

興味がある人は、GitHubで適当な公開リポジトリを閲覧してみると良いでしょう。

どういった機能が備わっているのか、体験できると思います。

色々あるとはいえ、学習コストとか導入コストが高いんでしょう?

まず学習コストについてですが、gitは話で知っている程度、の私は

おおよそ一週間(チュートリアルなどで1~2日、実際の作業を数件こなしてようやく慣れる)

といったところでした。

これを高いとみるか低いとみるかは人によると思いますが、

svn触ったことある人なら、有識者のサポートを受けながらなら

飲みこみは早いだろうなというのが所感です。

導入コストもそこまでかからないです。

GitBucketと呼ばれるGitHubクローンのサービスは、

Tomcat等の、warファイルをデプロイできる環境があれば

すぐにサービス開始できます。

ただし、gitは汎用性が高い分、

運用を間違えるとその恩恵は得られません。

  • チーム内で(コマンド集やチュートリアルなどの)リファレンスを充実させる。
  • 運用ルールはしっかりを決めておく。

最低限、この2点はクリアできないと、

導入後にバタバタしてしまうと思います。

結局導入するのってどうなのよ?

100人の開発者に聞けば、90人は「効率が上がった」と答えるでしょう。

今回の場合、私がGitBucketの環境構築と、

ドキュメント整備(チュートリアル、Tips集の作成)を行ったので、

参考までにどんな感じで進めたか紹介します。

①メンバーの説得

上で話したようなことを言って良さを知ってもらう。

②環境構築

GitBucketを社内サーバに建てました。

GitLabはIE対応していないので今回は断念。

GitHubの非公開リポジトリはお金がかかるのでこれも断念。

(大体1~2人日。ブログなどで導入方法はたくさん紹介されているので、そこまで詰まらず)

③運用ルール、ドキュメント整備

運用ルールについては、a successful git branching modelを参考に

  • masterブランチ:最終的なリリースブランチ
  • developブランチ:開発途中のソースコードが挙がるブランチ。全体共有リポジトリ。
  • workブランチ:各作業者が作成して、developにマージするための作業用ブランチ(複数作られる)

をブランチモデルとし、

workブランチで各対応(バグ改修、処理追加)を行った後、developブランチに

pull request(作業が終わったので全体共有リポジトリにマージしてください という合図)を

作成してもらう、といった方針にしました。

ドキュメントについては、ほとんど

サルでも分かるgit を読んでもらうことにしました。

その後、自己PRを追加するという課題を振って、

workブランチ作成→コミット(プッシュ)→pull requestを送る

という一連の流れを体験してもらってから、実際の作業を行ってもらいました。

この際の各操作は、最初の体験者にTips集としてまとめさせ、

後の作業者に伝えてもらいます。

色々やってみての感想

個人的な意見ですが、

①運用ルールとかドキュメント整備はしっかりしましょう

→gitは色々出来る分、複雑です。作業者がやるべき作業は端的にまとめましょう

②色々大変ですが、それでも得られるメリット(効率化)は大きいです。

→ただし例えば仕事とかで、いきなり大規模開発とかに導入するのは危険だと思います。小さい開発や落ち着いている開発で実績を積んでから

全体へ展開していく方針がよいでしょう。

関連記事

no image

gitbucketで再起動に失敗してDBエラーが起きた話

とあるAdvent calendarを書くことになったのですが、そもそもブログを更新してなかったので

記事を読む

no image

jenkinsのジョブでIllegalArgumentExceptionが起きた

Jenkinsのジョブで、 java.lang.IllegalArgumentException:

記事を読む

no image

ExcelでActiveXコントロールを挿入すると「オブジェクトを挿入できません」とエラーが出る。

とあるExcelファイルであるマクロを実行しようとしたのですが、 ActiveXオブジェクトの

記事を読む

no image

javaでzip作る時の圧縮レベルの話

いわゆる無圧縮zipファイルをjavaで作ることがあったので、覚え書きです。 ついでに圧縮レベ

記事を読む

no image

chromeで「このウェブページにアクセスできません」が出たときの対処法

自宅以外の環境でchrome使おうとして、検索した瞬間に「このウェブページにアクセスできません」と出

記事を読む

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

no image
学生時代に1ミリも知らなかったJavaの開発風景

※この記事は、苫小牧高専 Advent Calendar 2016 -

no image
gitbucketで再起動に失敗してDBエラーが起きた話

とあるAdvent calendarを書くことになったのですが、そもそ

no image
機械学習について簡単におさらいした

機械学習について、実際あんまりよくわかってなくね?ってなったので

no image
svnを使っている作業場でgitを普及させるためにやったこと

今回は、ある作業場でgitを普及させたい!という思いから、私が個人的に

no image
jenkinsのジョブでIllegalArgumentExceptionが起きた

Jenkinsのジョブで、 java.lang.IllegalArgu

→もっと見る

PAGE TOP ↑