本記事の対象読者
プロジェクトで初めてGitを使う人や、初心者向けです。おそらく経験のあるエンジニアなら本記事で私が経験したようなことは起こらないはずです。
前提条件
ソースコードの管理方法として、自分のソースコードは諸事情によりローカルGitで管理して、顧客にソースコード一式をファイルサーバ経由で共有するという方式をとっていました。また自分はプロジェクトに参加して間もない時で、引き継ぎがない状況でほとんど環境についての説明もなかった時に事件が起こりました。
※そもそもこの状況があまりよくないのはその通りですね。
発生した問題：改行コードが違うと問い合わせ
- ソースコードは LF（Line Feed）で統一管理
- 自分の環境でもLFで管理しており、修正を加えたファイルだけCRLF（Carriage Return + Line Feed）にするという指示通りにGitにコミット
- 以下のGitコマンドでarchiveを作成してして顧客に共有で終わり！と思った
git archive --format=zip -o output.zip HEAD
- 顧客から「改行コードがすべてCRLFになっている」と問い合わせがあった
結果的に原因追及を含めてかなり無駄な工数を費やしてしまいました。
原因の特定
| 設定項目 | 内容 |
|---|---|
core.autocrlf=true |
Gitが自動で改行コードを変換していた |
.gitattributes に * text=auto
|
改行コードをGitが自動判定していた |
この設定により、Gitが「親切心」で改行コードを変換してしまい、意図しない差分が発生しているのが原因でした。また作業ファイル自体は想定通りの修正に見えますが、Gitでアーカイブを作成したときは、上記の設定で出力されるため、意図しない改行コードになってしまいました。
※納品する前にエクスポートしたファイル一式とGitのファイルとを比較していなかったのがそもそもの問題で、もっと慎重に作業をすべきだったと反省しています。
対処法：自分の環境だけ改行コードを変えずに扱う方法
1. 改行コードの変換を無効化する（ローカル限定）
git config --local core.autocrlf false
これにより、改行コードの自動変換を防げます。
2. 顧客の .gitattributes を尊重しつつ差分を出さないには？
- 顧客の .gitattributes をそのまま使用
- 自分の環境では core.autocrlf=false にして、Gitの変換を停止
- 差分が出るファイルは eol=CRLF を明示的に指定
- 以下のように改行コードを勝手に変えないように無効化
.gitattributes
* -text
今後同じような事態を防ぐためのチェックリスト
- .gitattributes の内容を確認したか？
- core.autocrlf の設定を見直したか？
- 顧客の環境と自分の環境の改行コードを一致させたか？
- 差分が出る前に改行コードをチェックしたか？
最後に：ソース管理が不十分なプロジェクトでは「Gitの改行コード設定」が地雷になる
引き継ぎがない状況では、こうした細かな設定がトラブルの火種になり精神的にもよくないです。Gitの挙動を理解し、環境に応じた設定を行うことで、無駄に工数を消費することやや混乱を防げます。