今年に入ってから、急速にGitが注目を浴びています。Google Trendsを見ると、Subversion、Mercurialなどに比べると圧倒的にGitの人気が高いのがわかります（図1⁠）⁠。

しかしながら、Gitを利用する人の意見は2つに分かれています。

• A．わかりにくい
• B．すごく便利だ

なぜこのようなに印象が二分されてしまうのでしょうか? 本稿では、「⁠Gitに潜む光と闇」と称してこれらの意見に対して考察していくことにします。

Gitはわかりにくい?

Gitがわかりにくいと思う人は、どうしてそう感じるのでしょうか。そのあたりのおおよその事情は下記のようなことだと考えられます。

（1）Subversionとコマンド体系が少し違う

バージョン管理ツールとして、Subversionを使っている方も多いと思います。しかし、GitはSubversionとコマンド体系が少し違っています。

また、svn catに対するgit showなど、同じ操作でもコマンド名が異なっているものも多くあります。中途半端にSubversionと同じだったり異なったりするのも混乱の原因と言えます。

（2）従来のバージョン管理システムと概念が異なる

Gitでは、上に述べたインデックスやローカルリポジトリなど、新しい概念が存在します。そのため、Subversionに慣れたユーザは混乱を来たすことがあります。

また、少し古い記事では「Gitはリポジトリが複数持ちリポジトリ間で編集内容（コミット）をやりとりできる」と書かれていることが多数あります。これはGitに代表される分散バージョン管理システムの大きな特徴です。ですが、これも混乱を来たします。この内容自身は間違ってはいませんが、多くの場合、共有リポジトリを立ててGitを利用します。共有リポジトリを前提に話をしたほうがわかりやすいのに、そうはなっていない解説が意外と多く見られます。

（3）エラーメッセージが出力されるがどうすればいいのかわからない

Gitを利用していて、エラーメッセージが出てもどうすればいいのかよくわからないことがあります。メッセージが日本語化されておらず英語で表示されるというのもありますが、そもそものメッセージがわかりにくい場合もあります。極端な例ですが、プッシュをしようとして、

$ git push
(gnome-ssh-askpass:23904): Gtk-WARNING **: cannot open display:

と表示されたとき、いったい何が原因でエラーとなり、どうしたら解決できるかわかるでしょうか?

（4）履歴操作の必要性に疑問

Gitではreset、reflog、rebaseなど、履歴操作を行うコマンドが追加されています。commitでさえ、--amendオプションを付けることにより直前のコミットを編集しなおすことができます。コミットメッセージの修正ならいざ知らず、そもそも履歴の改変というは、バージョン管理の根底を覆すのではないかと思えてしまいます。それなのに、rebaseを使ってコミットをきれいにしろと煽（あお）る輩もいて混乱を来たします。

そして、「⁠わかりにくい」という極めつけの理由は、

• Linuxが前提となっている記述が多い

ことでしょう。ほかにもあるかもしれませんが、Gitを難しいと思っている人は、上記の一つや二つに心当たりはあるのではないでしょうか?

Gitがすごく便利な理由

一方、Gitはすごく便利だと思っている人も多数いるのも事実です。

（1）GitというよりGitHubがすごい

Gitリポジトリのホスティングサービスは便利です。趣味で作成したコードで、公開してもかまわない場合、簡単にGitリポジトリを作成、公開できるGitHubは非常に役に立ちます。

フォーク機能により、開発が停止したオープンソースソフトウェアの開発を引き継ぐことができますし、また、自分が開発したコードに興味がなくなってもほかに有用だと感じる開発者がいればフォークされて開発が継続されます。

フォークされたコードがさらにフォークされてもネットワークグラフ機能で誰のフォークが一番メンテナンスされているか、簡単に知ることができます。

IssueやWiki機能を利用すれば、簡単ではありますがタスク・バグ管理やドキュメントの管理も行うことができます。

GitではなくGitHubがすごいのです。

（2）履歴操作ができる

コミットメッセージを間違えたり、コミットにおかしなコードを含めてしまったりした場合でも、履歴操作機能で簡単に修正・削除できます。誤ってisoファイル（CD/DVDイメージ）などの大きなファイルをコミットしてしまった場合、リポジトリ操作が重くなりますが、過去すべての履歴に遡りきれいさっぱり削除できます。

また、rebaseにより、ブランチを作成したあと、メインライン（masterブランチ/Subversionではtrunkと呼ばれる）が変更された場合でも、ブランチにメインラインの変更を適用し、メインラインの最新からの差分という形にブランチの履歴を並び替えてきれいにできます。

（3）慣れてしまえば無問題

冒頭でGitのコマンドはわかりにくいと述べましたが、実際には慣れてしまえば問題ありません（逆にGitに慣れた状態でSubversionを利用するとコマンドがわからず、混乱を来たすこともあります⁠）⁠。

アメリカの心理学者のG.M. ストラットの、上下逆さまに見えるメガネをかけると、最初は嘔吐をするほどの違和感に襲われるが、数日すると自分が見ている方向と上下が一致するようになり普通に生活できるようになる、という実験が有名ですが、要は慣れの問題です。人間の順応性はすばらしいものです。

（4）莫大なTipsに使えば使うほど味が出る

GitはSubversionと比べるとコマンド自身の数も多いし、1つのコマンドでできることも多くあります。使い込めば使い込むほど新しい発見があり、いろいろなことができるようになります。噛めば噛むほど味が出てくるスルメのようなものなのです。

Gitという大海原を攻略するには

Gitは、大海原だ。最初に利用したときにそう思いました。この大海原を攻略するために書いた拙書が「Gitポケットリファレンス」です。Gitが難しいと思っている読者でも「Gitという大海原の海流の流れ」をきちんと掴（つか）んでもらえるように、書籍ではチートシート（図2）や第1章の導入分でGitを利用したワークフローの解説をしています。

筆者は、大手SIerで開発環境の標準化も行っていた経歴を持っており、前述のような解説は全社でGitを使ってもらうにはどうしたら良いか、という観点で記述しました。また、業務での開発ではWindows PCが多数を占めることから、WindowsへのGitのインストール方法も丁寧に解説しています。OSを決めるのは開発者やユーザなのだから、利用者に合わせた解説をすることは重要だと思っています。

リファレンス部では、各コマンドごとに主要な機能を丁寧に解説し、エラーが発生したときの対処方法も記載しました。たとえば、冒頭で紹介したgit pushのエラーの対処方法は図3のように記載されています。

第3章ではALMinium/Gitoliteを利用したリポジトリ運用の話や、フックの話、GitHubの紹介などを行っています。フックは、フックスクリプトの実行タイミングが若干わかりにくいですが、フローを使ってわかりやすく解説するように心がけました。

図4は、pushが実行されたときに、サーバ側でブランチごとにupdateスクリプトが最初に実行され、次にpost-receiveスクリプトが、最後にpost-updateスクリプトが実行されることを示しています。書籍では各スクリプトの詳細な使い方の説明も記載していますが、ここでは省略します。

とあるGitの（以下自主規制）

Gitは、ファンタジー系のゲームで出てくる魔道士のように、使っていくうちにどんどん新しい呪文（コマンド）を覚えて学習していき、高度な使い方ができるようになります。そこで、表紙のデザインはデザイナの方に魔道書っぽくしてもらいました。個人的には非常に気に入っており、Gitポケットリファレンスが好評価を受ける因果の1つとなっていると信じて疑わないものですが、Amazonの書評やTwitterでのつぶやきを読む限り、女性の読者が皆無なので「ヲタ向けだったか」と若干後悔しています。

また、ポケットリファレンスシリーズということもあり、手元において利用することを前提とするべく、クオリティを落とさないようにページ数を抑えるように努力しました。コンパクトなのでポケットに入れて持ち運ぶことも可能です。

Gitポケットリファレンスの「はじめに」は、最初はまじめに書いていましたが、内容がまじめなので少しくらいは遊び心を入れたいと思い、ちょっと趣向を凝らしてみました。この「はじめに」では、「⁠Gitは難しくて便利である」というのを一言で「ツンデレ」と評して論じています。Gitポケットリファレンスを購入するつもりがない方も、立ち読みでかまいませんので、「⁠はじめに」だけは読んでみてください。