8.1 Git のカスタマイズ - Git の設定

デフォルトでは、コミットやタグのメッセージを編集するときには、ユーザーがデフォルトエディタとして設定したエディタ（ $VISUAL または $EDITOR）が使われます。デフォルトエディタが設定されていない場合は vi エディタが使われます。 このデフォルト設定を別のものに変更するには core.editor を設定します。

これで、シェルのデフォルトエディタに関係なく、Git でメッセージを編集する際には Emacs が起動されるようになりました。

システム上のファイルへのパスをここに設定すると、Git はそのファイルをコミット時のデフォルトメッセージとして使います。 たとえば、次のようなテンプレートファイルを作って ~/.gitmessage.txt においたとしましょう。

git commit のときにエディタに表示されるデフォルトメッセージをこれにするには、commit.template の設定を変更します。

すると、コミットメッセージの雛形としてこのような内容がエディタに表示されます。

コミットメッセージについてチーム内に所定の決まりがあるのなら、その決まりに従ったテンプレートをシステム上に作って Git にそれを使わせるようにするとよいでしょう。そうすれば、その決まりに従ってもらいやすくなります。

core.pager は、Git が log や diff などを出力するときに使うページャを設定します。 more などのお好みのページャを設定したり (デフォルトは less です)、空文字列を設定してページャを使わないようにしたりできます。

これを実行すると、すべてのコマンドの出力を、どんなに長くなったとしても全部 Git が出力するようになります。

署名入りの注釈付きタグ (作業内容への署名 で取り上げました) を作る場合は、GPG 署名用の鍵を登録しておくと便利です。 鍵の ID を設定するには、このようにします。

これで、git tag コマンドでいちいち鍵を指定しなくてもタグに署名できるようになりました。

プロジェクトごとの .gitignore ファイルでパターンを指定すると、git add したときに Git がそのファイルを無視してステージしないようになります。これについては ファイルの無視 で説明しました。

ですが、作業中のすべてのリポジトリで、ある特定のファイルを無視したい場合もあります。 Mac OS X を使っているのなら、 .DS_Store というファイルに見おぼえがあるでしょう。 使っているエディタが Emacs か Vim なら、 ~ で終わるファイルのことを知っていることと思います。

このような設定を行うには、グローバルな .gitignore のようなファイルが必要です。 ~/.gitignore_global ファイルへ次の内容を書き込んで、

その上で git config --global core.excludesfile ~/.gitignore_global を実行すれば、これらのファイルで手を煩わすことは二度となくなります。

Git でコマンドを打ち間違えると、こんなふうに表示されます。

Git は気を利かせて、何をしたかったのか推測はしてくれますが、実行まではしません。 help.autocorrect を 1 にしておくと、 Git は実際にそのコマンドを実行しようとします。

“0.1 seconds” という箇所に注目してください。 help.autocorrect は整数値で、0.1秒単位での時間を表しています。 そのため、仮に 50 を設定したなら、自動修正したコマンドが実行される前に 5 秒の猶予が与えられます。

Git は自動的に大半の出力に色づけをします。ですが、この挙動が気に入らないなら、そのためのマスタースイッチがあります。 ターミナルへの出力への色付けをすべてオフにするなら、以下のようにします。

デフォルトの設定は auto で、直接ターミナルへ出力する場合には色付けを行いますが、パイプやファイルへリダイレクトした場合にはカラーコントロールコードを出力しません。

また always を指定すると、ターミナルであってもパイプであっても色をつけます。 always を使うことは、まずないでしょう。たいていの場合は、カラーコードを含む結果をリダイレクトしたければ、 Git コマンドに --color フラグを渡せばカラーコードの使用を強制できます。 ふだんはデフォルトの設定で要望を満たせるでしょう。

どのコマンドをどのように色づけするかをより細やかに指定したい場合、コマンド単位の色づけ設定を使用します。 これらの項目には true 、 false あるいは always が指定できます。

さらに、これらの項目ではサブ設定が使え、出力の一部について特定の色を使うように指定することもできます。 たとえば、diff の出力で、メタ情報を黒地に青の太字で出力させたい場合は次のようにします。

色として指定できる値は normal、 black、 red、 `green、 yellow、 blue、 magenta、 cyan、 white のいずれかです。先ほどの例の bold のように属性も指定できます。bold、 dim、 ul （下線つき）、 blink、 reverse （文字と背景の色を逆にする）のいずれかを指定できます。

自分が Windows で開発している一方、チームの中に Windows 以外の環境で開発している人がいる場合（逆も同様）には、改行コードの問題に巻き込まれることがありがちです。 Windows ではキャリッジリターンとラインフィードでファイルの改行を表すのですが、Mac や Linux ではラインフィードだけで改行を表すという違いが原因です。 これはささいな違いではありますが、さまざまなプラットフォームにまたがる作業では非常に面倒なものです。Windows のエディタには、LFだけの改行をだまってCRLFに置き換えたり、ユーザがEnterキーを押下した際にCRとLFの両方を挿入したりするものが数多くあります。

Git はこの問題に対処するために、コミットする際には行末の CRLF を LF に自動変換し、ファイルシステム上にチェックアウトするときには逆の変換を行うようにできます。 この機能を使うには core.autocrlf を設定します。

Windows で作業をするときにこれを true に設定すると、コードをチェックアウトするときに行末の LF を CRLF に自動変換してくれます。

Linux や Mac などの行末に LF を使うシステムで作業をしている場合は、Git にチェックアウト時の自動変換をされてしまうと困ります。しかし、行末が CRLF なファイルが紛れ込んでしまった場合には Git に自動修正してもらいたいものです。 コミット時の CRLF から LF への変換はさせたいけれどもそれ以外の自動変換が不要な場合は、core.autocrlf を input に設定します。

この設定は、Windows にチェックアウトしたときの CRLF への変換は行いますが、Mac や Linux へのチェックアウト時は LF のままにします。

Windows のみのプロジェクトで作業をしているのなら、この機能を無効にしてキャリッジリターンをそのままリポジトリに記録してもよいでしょう。その場合は、値 false を設定します。

Git には、空白文字に関する問題を見つけて修正するための設定もあります。 空白文字に関する主要な六つの問題に対応するもので、そのうち三つはデフォルトで有効になっています。残りの三つはデフォルトでは有効になっていませんが、有効化することもできます。

デフォルトで有効になっている設定は、行末の空白文字を見つける blank-at-eol 、ファイル末尾の空白文字を見つける blank-at-eof 、行頭のタブ文字より前にある空白文字を見つける space-before-tab です。

デフォルトでは無効だけれども有効にすることもできる三つの設定は、行頭がタブ文字でなく空白文字になっている行を見つける indent-with-non-tab （空白文字の数は tabwidth オプションで制御可能）、行内のインデント部分にあるタブ文字を見つける tab-in-indent 、行末のキャリッジリターンを許容する cr-at-eol です。

これらのオン・オフを切り替えるには、core.whitespace にカンマ区切りで項目を指定します。 無効にしたい場合は、設定文字列でその項目を省略するか、あるいは項目名の前に - をつけます。 たとえば cr-at-eol 以外のすべてを設定したい場合は、このようにします。

git diff コマンドを実行したときに Git がこれらの問題を検出すると、その部分を色付けして表示します。修正してからコミットするようにしましょう。 この設定は、git apply でパッチを適用する際にも助けとなります。 空白に関する問題を含むパッチを適用するときに警告を発してほしい場合には、次のようにします。

あるいは、問題を自動的に修正してからパッチを適用したい場合は、次のようにします。

これらの設定は、git rebase コマンドにも適用されます。 空白に関する問題を含むコミットをしたけれどまだそれを公開リポジトリにプッシュしていない場合は、 git rebase --whitespace=fix を実行すれば、パッチを書き換えて空白問題を自動修正してくれます。

デフォルトでは、Git はプッシュで受け取ったオブジェクトの SHA-1 チェックサムが一致していて有効なオブジェクトを指しているということをチェックさせることができます。 ですが、デフォルトではこのチェックは行わないようになっています。このチェックは比較的重たい処理であり、リポジトリのサイズが大きかったりプッシュする量が多かったりすると、毎回チェックさせるのには時間がかかるでしょう。 毎回のプッシュの際に Git にオブジェクトの一貫性をチェックさせたい場合は、receive.fsckObjects を true にして強制的にチェックさせるようにします。

これで、Git がリポジトリの整合性を確認してからでないとプッシュが認められないようになります。壊れたデータをまちがって受け入れてしまうことがなくなりました。

すでにプッシュしたコミットをリベースしてもう一度プッシュした場合、あるいはリモートブランチが現在指しているコミットを含まないコミットをプッシュしようとした場合は、プッシュが拒否されます。 これは悪くない方針でしょう。しかしリベースの場合は、自分が何をしているのかをきちんと把握していれば、プッシュの際に -f フラグを指定して強制的にリモートブランチを更新することもできます。

このような強制更新機能を無効にするには、receive.denyNonFastForwards を設定します。

もうひとつの方法として、サーバー側の receive フックを使うこともできます。こちらの方法については後ほど簡単に説明します。 receive フックを使えば、特定のユーザーだけ強制更新を無効にするなどより細やかな制御ができるようになります。

denyNonFastForwards の制限を回避する方法として、いったんブランチを削除してから新しいコミットを参照するブランチをプッシュしなおすことができます。 これを無効にするには、 receive.denyDeletes を true に設定します。

これは、プッシュによるブランチやタグの削除を一切拒否し、誰も削除できないようにします。 リモートブランチを削除するには、サーバー上の ref ファイルを手で削除しなければなりません。ACL を使って、ユーザー単位でこれを制限することもできますが、その方法は Git ポリシーの実施例 で扱います。