複数環境(Windows, Linux, Mac)におけるGitでの改行コードの扱い方

photo credit: Jeremy Kendall via photopin cc

テクニカルサポートをしていた、WindowsとLinuxの混在環境で開発しているチームから改行コードで課題が報告されたので、それへの対応手順を記載する。

前提

Repositoryに入れる改行コードはLFのみにする。

自動変換

調査

以下のコマンドでとりあえず、自動チェックがないか調べる。

$ git config --help
:
       core.autocrlf
           Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files
           that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does
           not have normalized line endings. This variable can be set to input, in which case no output conversion is performed.
:

core.autocrlfというGitglobalオプションで改行コードの自動変換を設定可能。

  • true:コミット時にCRLF->LFに変換し、チェックアウト時はLF->CRLFに変換する
  • input:コミット時にCRLF->LFに変換する
  • false:何もしない

関連調査

似たような文言の設定もあるので、そちらも確認する。

$ git config --help
:
       core.safecrlf
           If true, makes Git check if converting CRLF is reversible when end-of-line conversion is active. Git will verify if a command modifies a file in the work tree either
           directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If this is not the case for
           the current setting of core.autocrlf, Git will reject the file. The variable can be set to "warn", in which case Git will only warn about an irreversible conversion but
           continue the operation.

           CRLF conversion bears a slight chance of corrupting data. When it is enabled, Git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that
           contains a mixture of LF and CRLF before the commit cannot be recreated by Git. For text files this is the right thing to do: it corrects line endings such that we have
           only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data.

           If you recognize such corruption early you can easily fix it by setting the conversion type explicitly in .gitattributes. Right after committing you still have the
           original file in your work tree and this file is not yet corrupted. You can explicitly tell Git that this file is binary and Git will handle the file appropriately.

           Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both
           cases CRLFs are removed in an irreversible way. For text files this is the right thing to do because CRLFs are line endings, while for binary files converting CRLFs
           corrupts data.

           Note, this safety check does not mean that a checkout will generate a file identical to the original file for a different setting of core.eol and core.autocrlf, but only
           for the current one. For example, a text file with LF would be accepted with core.eol=lf and could later be checked out with core.eol=crlf, in which case the resulting
           file would contain CRLF, although the original file contained LF. However, in both work trees the line endings would be consistent, that is either all LF or all CRLF, but
           never mixed. A file with mixed line endings would be reported by the core.safecrlf mechanism.
:

core.safecrlfというGitglobalオプションで改行コード混在時に自動変換しないという設定も可能。

参考資料