気をつけて！Git for Windowsにおける改行コード

# はじめに
このタイトルにあるような内容は
`git windows 改行コード`
などと検索すればたくさんでてくることと思われます。

git for windowsでデフォルトの設定でインストールした場合、
![2015-12-25_145945.png](https://qiita-image-store.s3.amazonaws.com/0/50783/072eee6f-54ea-eec5-0467-c62d706b15f8.png)

`Checkout Windows-style, commit Unix-style line endings`
の設定となり、チェックアウトの際の改行コードが`LF`から`CRLF`にしてしまう設定です。
gitの設定を`git config -l`でみると`core.autocrlf=true`となっているかと思われます。

他の方の記事を読むと、その設定が煩わしいというようなことが書かれています。
確かに。

インストール後に変更する場合は、
`git config --global core.autocrlf true`の`true`を変えることで変更が可能です。

|設定|チェックアウト時|コミット時|
|:-:|:-:|:-:|
|true|LF -> CRLF|CRLF -> LF|
|input|変換しない|CRLF -> LF|
|false|変換しない|変換しない|

これをみると`input`や`false`は`LF -> CRLF`の自動変換を行わないので、これらを選んでしまいそうですが、

大規模開発で多数の開発者が`true`でインストールしてしまった場合、わざわざ変更をしてもらうまでの悪影響があるのか？がわからなかったので、それについて調べた結果を記載しようかと思います。また、これを書くきっかけとなった私のチームではまった落とし穴について書こうと思います。

# `core.autocrlf`を`true`に設定をした場合
`core.autocrlf`を`true`に設定をした場合について整理します。
チェックアウトやコミットした場合の動きや、開発者がCRLFでファイルを作成した場合の動きは以下のようになります。

![スクリーンショット 2015-12-25 20.20.06.png](https://qiita-image-store.s3.amazonaws.com/0/50783/65b657b5-8564-a9da-8e9b-cedfde26f82b.png)

上記の図から確かにwroking directory上では`CRLF`と`LF`が混在してしまう可能性がありますが、
repository上のファイルが`LF`である以上、`core.autocrlf`を`true`に設定をしていても問題がないように思えます。

## 問題となる設定
では、repositoryにCRLFが紛れてしまう恐れがある設定は何でしょうか。
それは`core.autocrlf`が`false`の場合です。
`core.autocrlf`を`false`にするということはチェックアウト時もコミット時も改行コードを変換しないということです。
そうした場合、以下のようなことになります。

![スクリーンショット 2015-12-25 20.59.39.png](https://qiita-image-store.s3.amazonaws.com/0/50783/38579528-6220-8d0e-b712-c064a220a718.png)

これではリモートリポジトリにも`CRLF`が紛れてしまい、他開発者にも影響がでてしまいます。
つまり、`core.autocrlf`は以下のどちらかがよいように思われます。

- `true`
- `input`

## ただもう一つ落とし穴が
ここで、もう一つ気をつけることがあります。実際、この落とし穴にはまったためこの記事を書こうと思いました。
それは、`core.autocrlf`を`true`にしていたことが原因でした。

注意が必要なのはMavenやGradleを利用してビルドを行う、ビルド職人たちです。
ビルド職人が`core.autocrlf`を`true`でチェックアウトし、ローカルのworking directoryでwindows以外のデプロイ資材を作成してしまうと
以下が示すように、資材の中にCRLFが含まれてしまう可能性があります。

![スクリーンショット 2015-12-25 21.37.26.png](https://qiita-image-store.s3.amazonaws.com/0/50783/ef3ef859-c59e-ab03-d5e7-fa396b3008c4.png)

シェルなどがCRLFとなってLinux環境に置かれた場合、大変恥ずかしいことになってしまいますね。
・・・。

## ここまでのまとめ
windows環境で開発を行っている開発者は
`git config --global core.autocrlf true`
または
`git config --global core.autocrlf input`
にしておけば問題ないように思われますが、
ビルド作業のことや、想定していない改行コードの不具合を出さないようにするには
`git config --global core.autocrlf input`
としておいた方がよいのではないでしょうか。

# Repository上の`CRLF`を`LF`に変換する方法
さて、`false`にしていて、`CRLF`のファイルをrepository上に作成してしまった場合は`LF`に変換してあげなければなりません。
調査中、以下の記事が親切丁寧にまとめていてくださいました。 
http://tech.nitoyon.com/ja/blog/2014/03/28/git-crlf-to-lf/

まんまなので、そんなに書きません。備忘用です。
1. Repository上に`CRLF`があるかどうかは以下のコマンドで。
　`git grep --cached -I $'\r'`
2. repositoryの改行コードをなにもせずにもってきたいので、以下の設定にします。
　`git config --global core.autocrlf input`
3. 修正したいのはrepository内の`CRLF`です。working directoryと同期をとるために削除してからcheckoutします。（ここは「勘違い」で説明します。）
4. エディタで`CRLF -> LF`の修正
　私はIntellij IDEAなので、以下の記事を参考に。
　http://qiita.com/tanakahisateru/items/1c9ddf8d33d6727269ec
5. コミット

# 勘違い
私がしていた勘違いです。
`git config core.autocrlf true`の設定で、`CRLF`がworkingディレクトリにあるとわかったとき、エディタで`CRLF -> LF`を修正して、コミットを行ったのですが、コミットした履歴がログに出てこず、困ってしましました。

しかし、よくよく整理をしてみると、working directoryが`CRLF`だったとしても、repositoryが
`LF`であった場合、改行コードだけの修正であれば内容に差はなく、ヒストリーは残らないということがわかりました。

なので、repositoryの改行をそのままにする`input`や`false`の設定にしておいてから、working directoryにチェックアウトをしてあげる必要があるようです。
※ただ、その際、working directoryを一度削除しないと、同期が取れないようです。