プロジェクトで Git を使ってみた感想とか

2009/12〜2010/06 くらいまでの案件で Git を使ってみたので、その感想その他です。毎度長くてごめんなさい。

Subversion の経験はそこそこある状態でのスタートです。

リポジトリ構成のポイント

ソースコードは Git、ドキュメントは Subversion で

Git はファイル名をバイト列で管理するので、Windows と Linux の両方で使いたい場合は日本語名のファイルは使えません。（今のところ対応予定もないとのこと。ファイルのコンテンツやコミットログについては UTF-8 で統一できるので問題ありません。）

ソースコードについては日本語名のファイルは含まれないので Git 管理でいいと思いますが、ドキュメントに関しては難しいので Subversion 管理にしました。

リポジトリの単位は細かく

Git では Subversion と違ってリポジトリの一部をチェックアウトすることができませんので、リポジトリの単位を Subversion よりも細かく切っておく必要があります。

たとえば私は Subversion では

hoge
├─doc
├─envs
│  ├─ci
│  ├─svn
│  └─trac
├─received
├─src
│  ├─branches
│  ├─tags
│  └─trunk
└─vendorsrc

こんな感じでリポジトリを構成して、

• アプリケーション部分は src/* に格納
• CI サーバの設定は envs/ci に格納
• Trac サーバの設定 envs/trac に格納
• SVN サーバの設定は envs/svn に格納

して、それぞれの環境では必要部分のみチェックアウトして使うことが多いんですが、Git ではこのような運用はできないので、

• hoge-ci
• hoge-svn
• hoge-trac
• hoge-app

みたいに細かくリポジトリを作成することになります。（このあたりは Mercurial も同じです）

Git 自体の感想

運用がイマイチだった点は置いておいて、ツールとして見た場合の感想をさらっと書いておきます。

利点

今回 Git を使ってよかったと感じたのは以下の点です。

• 他の開発者に影響を与えずに気軽にコミットできる
• push する前であればコミット内容を書き換えられるので、間違いに気づいても取り返しがきく
• 何かミスしても（原理上）やり直しが効くので安心感がある
• GitHub をより深く利用できた
  • 今回 Rails の案件だったんですが、GitHub で管理されているプラグインなんかも多いので

「リポジトリに接続できない状態できる」（移動中にノート PC で開発する等）というのも 分散 VCS の利点として挙げられることが多いですが、そもそもプロジェクト関係のファイルの持ち出しが禁止みたいな雰囲気なので、この点では恩恵はありませんでした。

欠点

• 学習コストが高い
• コミットログが一直線でないのでわかりにくい
• リビジョンが番号で管理できないので指定しにくい

やはり一番の問題は学習コストです。チーム内の勉強会で WEB+DB PRESS Vol.50 の Git 特集はやっておいたんですが、それでも実際使ってみると混乱していました。

Subversion に比べると

• インデックスの概念がある
• ローカル／リモートリポジトリの概念がある
• ブランチ／タグの概念がディレクトリ以外の形である

ということで、ただでさえ構造が複雑です。（もともと Subversion が「CVS はブランチ等がわかりにくかったから単純な仕組みにしよう」というノリだったはずなので、Subversion と比べて複雑なのは仕方ないですが・・・。）

その上、コマンドの体系（オプションや引数を省略した場合に何が対象になるか等）が統一されていないので、コマンドがなかなか覚えられません。ちょっと普段の運用から外れたことをやろうとすると、結構時間がとられたりしました。

経験者に聞ける環境であれば問題ないかもしれませんが、それなりに時間が取られることは覚悟しておいたほうがいいです。

運用

今回の運用（悪い例）

完全に SVN を引きずった感じの運用になっていました。

• 中央リポジトリを用意して、各自がそこにコミットする。
• 今回は上流のリポジトリが master で、開発者は dev ブランチにコミットする。
  • 上流のリポジトリ云々は id:yun_kichi が書いてくれてます
    • git-svn を使って、Subversion のリポジトリと連携 - yun_kichiの日記
    • git-svn から git への移行方法 - yun_kichiの日記
• レビューの前に dev ブランチに push して、レビュー用のサーバで dev を pull してその環境でレビューする
  • 前の案件では「開発環境（Windows）では動くけどステージング環境（Linux）では動かない」というようなケースがたまにあったので、それを防ぐためにこのような運用にしていました

問題点／改善点

ソースコードの受け渡しやレビューの際にはに中央リポジトリに push するしかなく、dev ブランチの履歴がぐちゃぐちゃになってしまっていました。対応ごとにまとまってコミットされているわけでもないし、（当初 git pull 時に --rebase オプションをつける習慣がなかったので）不要なマージが発生しまくりでグラフが理解不能なレベルでした。このあたりはトピックブランチも使っておけばずいぶんすっきりした気がします。

「レビュー前に中央リポジトリに push する」というルールは DVCS の特長を生かせないので勿体なかったです。各自が公開リポジトリを用意しておいて、そこに push してレビュー用サーバに持って行く形がよかった気がします。そうすれば、中央リポジトリのログはより綺麗な形に保てたでしょう。

細かい Tips 等

• ブランチやマージで混乱したら、gitk --all でリビジョングラフを開いて、たまにリロードするとわかりやすいかも
• git grep が地味に便利。git で管理されているファイルすべてが対象でなくて、カレントディレクトリ以下の管理ファイルが対象なので、その点だけ注意。
• TortoiseGit は基本的な運用には耐えられるけど、git pull --rebase ができなかったり、remotes の設定がうまく使われなかったり、stash の名称を指定するオプションがなかったり？と微妙に機能不足。
  • pull --rebase 相当の動作設定は設定ファイルを編集すればできた気がする（追記: branch..rebase を true に設定すれば OK？）ので、必要ならこれを使いましょう。
  • ただ、blame は TortoiseGit のものを使っていました。履歴を追いやすいので。
  • TortoiseGit にも↓に書いた stash できない問題があるみたい。
    • <Git> msysGit の git stash や git rebase --onto でエラーの回避 - miauの避難所

その他雑感

うまくまとまらないので適当に思ったことを書いておきます。

• 今回 Redmine を使ったけど、GitHub みたいにグラフ表示できるわけではないのでわかりにくかった
  • 各自の公開リポジトリも管理できるし GitHub を使ってしまえばいいんだけど、会社のポリシーで「社外ネットワークは使うな」と言われてしまいそうなので、社内で似たようなサーバを立てる必要があるかも

• レビュー手順を簡素化したい
  • 今まで ReviewBoard とか Peer Review Plugin とかも試したことはあるけど、パッチをアップロードする運用はまどろっこしくて定着しなかったので、チケット番号やリビジョン範囲を指定する程度で使えるレビューツールを探したい

• コミット時のメールは送るべきか？
  • SVN の運用に合わせて送るようにしてたけど、入門Git によるとこれは送るべきではないとのこと。
  • ただ、著者のひとは Linux カーネルみたいな大規模なオープンソース開発を念頭に置いている気がするので、社内で少人数が使うのであればコミット時のメールは送るべきだと思う。
    • そのコミットを見るだけで指摘できるような点（誤字だったりコーディングルール違反だったり一行見ただけでわかるようなロジックの不備だったり）は、早いタイミングでつぶしておいたほうがいいので。
  • ただ、こうしてしまうと rebase -i のときにまたすべてのメールが送られてしまう。変更があった点だけメールが送れるような仕組みがほしい。

• push されていないコミットの情報がどこにも共有されないのがちょっと困る
  • オープンソースコミュニティでは利用者も多いし push されてないコードは誰の目にも触れないのがいいんだけど、業務では最後まで push されないコミットというのは少ないはず
  • 「対応完了のつもりが push されていなかった」という場面は何度も遭遇したし、これを見つける仕組みが欲しい
  • あと、push 待ちの状態で開発メンバが入院して困ることもあった。
  • push していないファイルは完全に見えないのではなく、Dropbox みたいに機会をみてサーバに送信して、「いざとなれば見られる」状態になっているのが理想。
  • ついでに、個人的には失敗したコミットも含めて全部履歴を残したい

• コマンド体系について
  • 上のほうにも書いたけど、統一されていないから覚えにくい。特定の状況で便利になるように考えられた結果がこれだとは思うけど、Perl で「省略した場合は $_ が対象になる」みたいな仕様と同じで、初心者には混乱の元になってしまっている気がする。
  • たぶん Git の開発初期に想定されていた運用は、オプションなしのコマンドでだいたいできるようになっているんじゃないかと思う。なので、オプションなしでの運用方法を解説したあとで、そのあとで次第にオプションを覚えていく感じのチュートリアルがあれば、コマンドの体系を理解しやすい気がする。

• 入門Git に「VCS を使ってデプロイするのは間違っている」みたいなことが書かれていたので、↓の主張にちょっと自信をなくしてしまった。
  • 本番サーバにチェックアウトしちゃダメですか？ - miauの避難所
  • まあ、今回も本番サーバで pull 運用にしてるのだけど。

• 実用Git の評判がいいから読みたいけど、Ebook の発売待ち。早く出てくれると嬉しい。

役に立ちそうなリンク

• Git 基礎最速マスター - 予定は未定Blog版
  • 開発環境の設定なんかについても載っているのでいいかなと。
  • ただ、msysGit の設定について、「最近の msysgit では ~/.inputrc は設定不要」みたいな情報も見かけたので、↓も併せて読んでおいたほうがいいかもしれません。
    • Git Cheat Sheets JP
  • msysGit では、これらの設定をすべて行っても色分けがうまくいかないコマンドがあったり、まだ完璧とはいえない気がします
• Subversion ユーザーが Git を使ってみた (基本操作編) - まちゅダイアリー(2010-05-06)
  • Subversion ユーザにはオススメ。一部の概念については図もあってわかりやすい。
• RSpec の入門とその一歩先へ - t-wadaの日記
  • Ruby での TDD/BDD のチュートリアルですが、Git を使った開発のリズムを掴むのにもオススメです。