10年以上前は CVS や Visual Source Safe を使っていたのですが、仕事の内容が変わって長いことバージョン管理システムには縁がない状態でした。
しかし、最近また仕事の内容が変わったのを機に (Subversion をスキップして！) git を導入してみました。
仕事環境は Windows がメインなので git も Windows 上に導入しましたが、使ってわかったのは Windows 環境でも全く問題なく使うことができるということです。
Web 検索すると古い情報が多くて Windows で動かすには苦労話が多いように見えますが、現状全く問題ありません。
といってもやはりノウハウが必要な部分もあるわけで、ここまでの自分の経験をまとめてみます。
クライアントは Git for Windows で決まり
ちょっと古い記事だと Cygwin と msysGit のどちらを選択するかという問題を取り上げていると思いますが、現状 msysGit で決まりだと思います。
git を使うだけのために Cygwin を導入するのは大掛かり過ぎます。
まあ、私は必要とすることがあるので Cygwin も導入してはいますが。
ところで現在の msysGit ですが、一般利用者向けパッケージは「Git for Windows」と名付けられており、「msysGit」は開発者向けパッケージの名前となっています。
ですので、git をバージョン管理に使いたいだけならば msysGit ホームページから「Git for Windows」の方をダウンロードしましょう。
現在のバージョンは Git-1.7.11-preview 版です。
古い記事で msysGit と言っているものは大抵の場合 Git for Windows を指しています。
この記事でも以降 Git for Windows という名前を使います。
GUI については TortoiseGit が良いよという記事が多いですが、今のところ私は Git for Windows パッケージに含まれている git-gui と gitk で間に合っています。
確かに一部の操作は GUI から実行できず、コマンドライン上で git を使う場面もありますが、私が日々の作業で使う主要な操作のほとんどは GUI 上で出来るので個人的には許容の範囲です。
会社によってはソフトウェアを入れるために IT 管理部門の説得に苦労するようなこともあると思いますが、そのような場合を考えるといろいろなものをあれこれ導入するより「公式の Windows 版 Git です！」といって Git for Windows だけを入れるのが苦労が少ないと思います。
Windows ファイルサーバーをそのまま利用しよう
同様にサーバーにソフトウェアを入れるのに困難が伴う会社は多いと思いますが、Git for Windows ならば問題ありません。
Windows サーバー上の共有フォルダをそのままベアリポジトリとして使えるからです。
以前書いたように Git for Windows では Windows の \\servername\folder\sub_folder\repository.git を以下の書式で参照できます。
//servername/folder/sub_folder/repository.git
サーバー上にリポジトリを置くとアクセス制御が必要となりますが、私の環境ではリポジトリ単位のアクセス制御で十分なので、共有フォルダのアクセス権設定によるアクセス制御で間に合っています。
エンコードの指定
Git for Windows 付属の GUI ツールを使っている限り、日本語の扱いも問題ないです。
最近は軟弱になって commit や diff などほとんどの操作を GUI でやっているのが幸いして日本語で困ったことはありません。
とりあえず言語関連について git-gui でやったことは「ファイル」－「編集」で 「ファイル内容のデフォールトエンコーディング」(原文ママ) を utf-8 にすることぐらいです。
(ひょっとしたらデフォルトだったかも)
また、EUC や SJIS のファイルも扱うことがあると思いますが、.gitattributes を適切に記述すれば git-gui や gitk 上できちんと日本語表示されます。
詳細は gitk の設定と合わせて記事にまとめていますので参照してみてください。
まあ、コマンドラインツールだとエディタやら less やら bash やらの日本語の扱いの話になってしまうので、どうしてもコマンドラインを使いたければ頑張ってハックしましょう。
私は GUI があるからいいや。
コマンドラインのお世話になるとき
そんな軟弱な私ですが、GUI で操作できない処理もあるのでコマンドラインを使うこともあります。
身近なところでは git fetch はできるのに git pull はできなかったりするのでコマンドラインを使います。
「fetch して修正して push して」という流れであれば git-gui の上で済ませられるのですけどね。
それとファイルの変更を取り消して、前回コミットの状態に戻す操作もそこそこ使います。
GUI だと「コミットから降ろす」＋「変更を元に戻す」操作になるので。
$ git checkout HEAD paths
他にもいくつかコマンドライン上で操作するものはありますが、git-gui には外部ツールを登録することができるので頻繁に使うものは登録してしまうというのも手です。
「git pull origin master」とか登録しておいた方が便利です。
この登録機能は次の Excel 差分比較のところでも使います。
Word や Excel の管理
Word にも対応していますが、特に Excel のファイル差分確認には WinMerge がお勧めです。
この WinMerge を差分確認ツールとして使用してみましょう。
なお、ここでは C:\WinMerge の下に WinMergeU.exe が置かれているものとします。
ちなみに WinMergeU.exe は Unicode 版、WinMerge.exe は ANSI 版 (Windows 9x や ME 用) です。
コマンドラインで使用する
外部コマンドを使う場合は git diff コマンドを使用するよりも git difftool コマンドを使って比較するのがお勧めです。
git diff で使うためには簡単なシェルスクリプトを用意しなければなりませんが、git difftool であればコンフィグファイルの設定のみで行けます。
以下のようにコンフィグファイル (例えばリポジトリの .git/config) に書いておきます。
[diff]
tool = WinMerge
[difftool "WinMerge"]
cmd = \"/c/WinMerge/WinMergeU.exe\" -u -wl -wr \"$LOCAL\" \"$REMOTE\"
あとは git diff の代わりにコマンドラインで git difftool と打つだけです。
1点注意ですが、複数のファイルの差分を取るように git diff を呼び出したときでも WinMerge は複数起動せずシリアルに 1つずつ差分を確認していくことになります。
これは一時ファイルを作って差分を取っている仕組みのため仕方がありません。
どうしても複数ファイルの差分を平行して確認したい場合は、Git Bash を複数起動して、それぞれの bash から 1つのファイルだけ指定して git difftool を起動すればよいです。
設定についてはこちらの記事を参考にさせていただきました。
そちらにはマージ用ツールとしての設定もありますので参照してみてください。
ちなみに私が設定した WinMerge のオプションは MRU リストへの追加抑止と Read-Only のためのものです。
WinMerge のオプションの詳細については公式マニュアルを参照ください。
git-guiで使用する
git-gui で使用したいときは「ツール」の「追加」で git difftool を登録するだけです。
起動も「ツール」メニューより行います。
gitk で使用する
「編集」「設定」で「外部diffツール」に以下のように入力します。
ちなみに「全体に追加」のチェック／アンチェックで global に設定するか local に設定するかを選ぶことができます。
c:/WinMerge/WinMergeU.exe
するとコンテキストメニューから「外部diffツール」を起動できるようになります。
先ほどの git difftool の場合と違って WinMerge へうまく動作制御のためのオプションを渡せなかったのですが、比較する 2つのファイル名は渡っているので実用上は問題ないでしょう。
以上で、一通りのツールから WinMerge を差分比較ツールとして起動できるようになりました。
これでかなり便利になると思います。
改行コードの処理
改行コード処理については、とりあえずインストール時はデフォルトの「Checkout Windows-style, commit Unix-Style line endings」(core.autocrlf = true) を選んでおけばよいでしょう。
しかし、場合によっては Linux から scp で取ってきたり、ルーターから Expect を使って取ってきたファイルを git リポジトリに突っ込むこともあると思うので、そんなときはリポジトリ単位で core.autocrlf = false に設定して、 CRLF の変換がされないようにした方が管理しやすいかも知れません。
$ git config --local core.autocrlf false
ファイル名の問題
日本語ファイル名も問題なく扱うことができます。
ただし、コマンドラインから git を使う可能性のある人は、ファイル名やフォルダ名に日本語を使う場合でも最初の何文字かは ASCII 文字でユニークに区別できる prefix をつけておいた方が良いでしょう。
そうしておけば日本語が入力できなくても bash の補完機能を使って苦労せず生きて行くことができます。
まとめ
CVS 等を使ってきた身としては、やはり「分散型」バージョン管理システムの概念を理解するのに時間を要しました。
しかし、実際に使ってみると、職業柄、出先での作業が多いので分散であるところに大いに助けられています。
ただ、課題もあって Excel のようにマージが難しいものについてはロック機構があればなあと思ってしまいます。
と言っても、そもそも MS Office 系のファイルについて共同作成をする際は章立てごとに担当を決めてファイルを分割して担当するような流れにしないと回らないような気もするので、試行錯誤しながらワークフローを決めていくことになるのでしょう。
それと「コミットを修正できるってどうよ」という感覚もありますが、その辺は頭を柔らかくして git を使って行きたいと思います。
最後に git について役に立った参考資料を挙げておきます。
この記事では git の基本的なところはすっとばして Windows での利用時に役立つ話ばかりしているので、使ったことがない人には辛い内容になっているかも知れませんが、もし興味があって「Windows 環境で動くなら手が出せるなあ」と思った人がいたらこれらを参考に是非 git を使い始めてみてください。
- Pro Git
- オンラインならばやはりここだと思います。
- WEB+DB PRESS Vol.50
- 雑誌の特集記事ですが、Git について実践的にわかりやすく書かれていて読みやすいです。
今となっては総集編
として購入するのが良いでしょう。
- WEB+DB PRESS Vol.69
- メインは GitHub の特集ですが、Git for Windows のインストールについても簡単に説明されています。
という本です。
で SELinux の仕組みが包括的にわかりやすく説明されているので、興味があればこれをお勧めします。
記事を書くにあたって以下のエントリを参考にさせていただきました。
