Git での改行コードの取り扱いについてきちんと調べたことがなくて、プロジェクトにおいては「みんなー! ただしく .gitconfig 設定してねー」という立場を取っておりました。 しかししかし、改行コード設定については、もはや個人の設定に正しさを求めるのではなく、リポジトリ単位に行う方がベストプラクティスのようです。
基礎知識
改行コードの取り扱いを面倒にしているのは、プラットフォーム毎に改行を意味するコードが異なることです。
| プラットフォーム | 改行コード |
|---|---|
| Windows | CR LF |
| Linux/OS X | LF |
Linux で作成され改行が LF で表現されたファイルがあるとします。これを、Windows で Checkout し、Windows 側で勝手に改行を CRLF で表現するようにしてしまうと、全行に差分が出てきてしまって、レビュー等が著しく大変になります。
このような状況を防ぐため、Git では、リポジトリ上のファイルは (基本的に) LF で表現するという考え方を採っています。
関連する設定
関連する設定については、以下の 2 つがあります。
| 設定 | 概要 |
|---|---|
core.eol |
作業ディレクトリ上のファイルに使用する改行コード。デフォルトは native |
core.autocrlf |
Git で改行コードを自動変換するかどうかを設定するフラグ。デフォルトは false |
core.eol のデフォルトである native は、Windows 上の改行コードを CRLF に、Unix/Linux/OS X では LF と解釈します。この変数を個別プロジェクトで設定するということはまずないと思います。
一方で、core.autocrlf については、デフォルトの false だと git は改行コードを as-is で扱いますので、リポジトリ上は、LF のファイルと CRLF のファイルが混在する状況が生まれがちです。
このため、プロジェクトの開発者に対して、Git がテキストファイルと判断した ファイルに対し、自動的に LF に変換する true を設定させることが多いのではないでしょうか。
リポジトリ単位での設定
こういう設定を個人の .gitconfig の正しさに求めると、誰か設定漏れをしていてリポジトリを破壊(!) することになります。
このため、個人任せではなく、リポジトリを clone した時点で開発者に強制できることが望ましい。それを行えるのが、.gitattributes です。
.gitattributes は、.gitignore と同様に指定したファイル名のパターンに合致するファイルに対し、特定の属性を与えるファイルです。
このうち、改行コードに影響を与えるのは以下のような属性。
| 属性 | 概要 |
|---|---|
text |
対象ファイルを「テキストファイル」として扱うものと指定し、改行コードの正規化を行うようにする |
eol |
text と一緒に指定することで、改行コードの正規化を行うようにする |
text には、単に宣言するだけでなくて、text=auto のような指定も可能ですし、eol には eol=crlf というような設定も可能です。
また、text に対して binary という指定もでき、この属性が指定されたファイルに対しては改行コードの指定は行われません。binary は -text -diff という指定のマクロとなっていて、改行コード変換と、diff が無効になります。
.gitattributes に合致するパターンが複数あった場合、後勝ちという仕様になっています。
このため、一般的な指定を先頭に、ファイル固有の指定を後にすることになります。
以下は、man gitattributes に出てくるサンプルですが、最初に全ファイルに対しての text=auto を指定することで、「テキストと判断したファイルについては、改行コード変換(LFへの変換) する」という設定にしています。
その後、以下のように、拡張子毎に詳細な設定を行っています。
.txtファイルは改行コード変換を行う (LFに変換).vcprojファイルは、改行コード変換を行う。ただし、CRLFに変換する.shファイルは、改行コード変換を行う。ただし、LFに変換する.jpgファイルには、改行コード変換を行わない
# * text=auto *.txt text *.vcproj text eol=crlf *.sh text eol=lf *.jpg -text
こういった指定を .gitattributes に指定してリポジトリにコミットすることで、今後当該のリポジトリを clone する開発者に対しては改行変換の設定が強制されることになり、より安全な開発が行えます。
