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

デフォルトでは、Git はシェル環境変数 VISUAL または EDITOR のいずれかを介して設定したデフォルトのテキストエディタを使用します。または、コミットおよびタグメッセージを作成および編集するために vi エディタにフォールバックします。そのデフォルトを別のものに変更するには、core.editor 設定を使用できます。

これで、デフォルトのシェルエディタが何に設定されていても、Git は Emacs を起動してメッセージを編集します。

これをシステム上のファイルのパスに設定すると、コミット時に Git はそのファイルをデフォルトの初期メッセージとして使用します。カスタムコミットテンプレートを作成する利点は、コミットメッセージを作成する際に、正しい形式とスタイルを自分自身（または他の人）に思い出させるために使用できることです。

たとえば、~/.gitmessage.txt に次のようなテンプレートファイルがあるとします。

このコミットテンプレートは、コミット者に件名を短く（git log --oneline 出力のため）、その下に詳細を追加し、問題またはバグトラッカーのチケット番号があれば参照するように促すことに注目してください。

git commit を実行したときにエディタに表示されるデフォルトメッセージとして Git に使用させるには、commit.template 設定値を設定します。

その後、コミットすると、エディタはプレースホルダーコミットメッセージとして次のように開きます。

チームにコミットメッセージポリシーがある場合、そのポリシーのテンプレートをシステムに配置し、Git がデフォルトでそれを使用するように設定することで、そのポリシーが定期的に遵守される可能性を高めることができます。

この設定は、Git が log や diff などの出力をページングする際に使用されるページャーを決定します。more またはお気に入りのページャー（デフォルトは less）に設定することも、空の文字列に設定することでオフにすることもできます。

これを実行すると、Git はすべてのコマンドの出力を、どんなに長くてもすべて出力します。

署名付きの注釈付きタグを作成している場合（作業に署名するで説明したように）、GPG 署名キーを設定として設定すると、作業が容易になります。キー ID を次のように設定します。

これで、git tag コマンドで毎回キーを指定することなくタグに署名できます。

ファイルの無視で説明したように、プロジェクトの .gitignore ファイルにパターンを記述することで、Git にそれらを追跡されていないファイルとして認識させないようにしたり、git add を実行したときにステージングしようとさせたりしないようにできます。

しかし、場合によっては、作業するすべてのリポジトリに対して特定のファイルを無視したいことがあります。お使いのコンピューターが macOS を実行している場合、おそらく .DS_Store ファイルに精通しているでしょう。お気に入りのエディターが Emacs または Vim の場合、~ または .swp で終わるファイル名を知っているでしょう。

この設定により、一種のグローバル .gitignore ファイルを作成できます。次のような内容の ~/.gitignore_global ファイルを作成した場合

…そして git config --global core.excludesfile ~/.gitignore_global を実行すると、Git はそれらのファイルについて再びあなたを悩ませることはありません。

コマンドのタイプミスをすると、次のようなものが表示されます。

Git は親切にあなたの意図を理解しようとしますが、それでも実行を拒否します。help.autocorrect を 1 に設定すると、Git は実際にこのコマンドを実行します。

「0.1 秒」という部分に注目してください。help.autocorrect は実際には、10分の1秒を表す整数です。したがって、これを50に設定すると、Git は自動修正されたコマンドを実行する前に、気が変わるのに5秒与えます。

Git はほとんどの出力を自動的に色付けしますが、この動作が気に入らない場合はマスター スイッチがあります。Git の色付きターミナル出力をすべてオフにするには、次のようにします。

デフォルト設定は auto で、出力が直接ターミナルに行く場合は色付けされますが、出力がパイプまたはファイルにリダイレクトされる場合は色制御コードを省略します。

always に設定すると、端末とパイプの違いを無視することもできます。これを望むことはめったにありません。ほとんどのシナリオでは、リダイレクトされた出力にカラーコードが必要な場合は、代わりに --color フラグを Git コマンドに渡して、カラーコードを強制的に使用させることができます。デフォルト設定がほとんどの場合に望ましいでしょう。

どのコマンドにどのように色を付けるかについてより具体的に指定したい場合、Git は動詞固有の色付け設定を提供します。これらの各設定は、true、false、または always に設定できます。

さらに、これらのそれぞれには、各色を上書きしたい場合に、出力の特定の部分に特定の色を設定するために使用できるサブ設定があります。たとえば、diff 出力のメタ情報を青い前景、黒い背景、太字のテキストに設定するには、次を実行します。

色は、normal、black、red、green、yellow、blue、magenta、cyan、または white のいずれかの値に設定できます。前の例のように太字のような属性が必要な場合は、bold、dim、ul（下線）、blink、および reverse（前景と背景を入れ替える）から選択できます。

Windows でプログラミングしており、そうでない人々と共同作業している場合 (またはその逆の場合)、どこかの時点で改行コードの問題に遭遇するでしょう。これは、Windows がファイル内の改行にキャリッジリターン文字とラインフィード文字の両方を使用するのに対し、macOS および Linux システムはラインフィード文字のみを使用するためです。これは微妙ですが、クロスプラットフォーム作業の信じられないほど迷惑な事実です。Windows の多くのエディタは、既存の LF 形式の改行をサイレントに CRLF に置き換えたり、ユーザーがエンターキーを押したときに両方の改行文字を挿入したりします。

Git は、ファイルをインデックスに追加するときに CRLF 改行を LF に自動変換し、コードをファイルシステムにチェックアウトするときにその逆を行うことで、これを処理できます。この機能は core.autocrlf 設定でオンにできます。Windows マシンを使用している場合は、true に設定します。これにより、コードをチェックアウトするときに LF 改行が CRLF に変換されます。

LF 行末を使用する Linux または macOS システムを使用している場合、ファイルをチェックアウトするときに Git にそれらを自動的に変換させたくはありません。ただし、CRLF 行末を持つファイルが誤って導入された場合、Git にそれを修正させたいと思うかもしれません。core.autocrlf を input に設定することで、コミット時に CRLF を LF に変換するように Git に指示できますが、その逆は行いません。

この設定により、Windows のチェックアウトでは CRLF 行末が残り、macOS および Linux システムとリポジトリでは LF 行末が残ります。

Windows プログラマで Windows 専用のプロジェクトを行っている場合、設定値を false に設定することで、この機能をオフにし、リポジトリにキャリッジリターンを記録できます。

Git は、いくつかの空白の問題を検出して修正するようにプリセットされています。6つの主要な空白の問題を調べることができます。3つはデフォルトで有効になっており、オフにできます。3つはデフォルトで無効になっていますが、有効にできます。

デフォルトで有効になっている3つは、行末のスペースを検索する blank-at-eol、ファイルの末尾の空白行を通知する blank-at-eof、および行頭のタブの前のスペースを検索する space-before-tab です。

デフォルトでは無効になっていますが有効にできる3つは、タブではなくスペースで始まる行を検索する indent-with-non-tab (tabwidth オプションで制御されます)、行のインデント部分のタブを監視する tab-in-indent、および行末のキャリッジリターンを Git が許容することを示す cr-at-eol です。

core.whitespace を、有効または無効にしたい値をコンマで区切って設定することで、Git にどのオプションを有効にしたいかを伝えることができます。オプションを無効にするには、名前の前に - を付けて指定するか、設定文字列から完全に除外することでデフォルト値を使用できます。たとえば、space-before-tab 以外をすべて設定したい場合は、次のようにできます（trailing-space は blank-at-eol と blank-at-eof の両方をカバーするショートハンドです）。

または、カスタマイズする部分のみを指定することもできます。

Git は git diff コマンドを実行したときにこれらの問題を検出し、色付けを試みるため、コミットする前に修正できる可能性があります。また、これらの値を使用して、git apply でパッチを適用するときに役立ちます。パッチを適用するときに、指定された空白の問題を含むパッチを適用している場合に警告するように Git に要求できます。

または、パッチを適用する前に Git に問題を自動的に修正させることもできます。

これらのオプションは、git rebase コマンドにも適用されます。空白の問題をコミットしたが、まだアップストリームにプッシュしていない場合は、git rebase --whitespace=fix を実行すると、Git がパッチを書き換えるときに空白の問題を自動的に修正します。

Git は、プッシュ中に受信されたすべてのオブジェクトがその SHA-1 チェックサムと一致し、有効なオブジェクトを指していることを確認できます。ただし、これはデフォルトでは行われません。これはかなりコストのかかる操作であり、特に大規模なリポジトリやプッシュでは、操作を遅くする可能性があります。Git にすべてのプッシュでオブジェクトの一貫性をチェックさせたい場合は、receive.fsckObjects を true に設定することで強制できます。

これで、Git は各プッシュが受け入れられる前にリポジトリの整合性をチェックし、不正な (または悪意のある) クライアントが破損したデータを導入しないことを確認します。

すでにプッシュしたコミットをリベースしてから再度プッシュしようとすると、またはリモートブランチが現在指しているコミットを含まないリモートブランチにコミットをプッシュしようとすると、拒否されます。これは一般的に良いポリシーですが、リベースの場合、あなたが何をしているかを知っていて、プッシュコマンドに -f フラグを付けてリモートブランチを強制的に更新できると判断するかもしれません。

Git に強制プッシュを拒否させるには、receive.denyNonFastForwards を設定します。

これを行うもう一つの方法は、後で説明するサーバーサイドの受信フックを使用することです。このアプローチでは、特定のユーザーのサブセットへの非ファストフォワードを拒否するなど、より複雑なことを行うことができます。

denyNonFastForwards ポリシーの回避策の 1 つは、ユーザーがブランチを削除し、新しい参照で再度プッシュすることです。これを回避するには、receive.denyDeletes を true に設定します。

これは、ブランチまたはタグの削除をすべて拒否します。どのユーザーも削除できません。リモートブランチを削除するには、サーバーから ref ファイルを手動で削除する必要があります。また、Git が強制するポリシーの例で学ぶように、ACL を介してユーザーごとにこれを行うより興味深い方法もあります。