712
597

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Git その2Advent Calendar 2015

Day 25

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

Last updated at Posted at 2015-12-25

はじめに

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

git for windowsでデフォルトの設定でインストールした場合、
2015-12-25_145945.png

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

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

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

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

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

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

core.autocrlftrueに設定をした場合

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

スクリーンショット 2015-12-25 20.20.06.png

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

問題となる設定

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

スクリーンショット 2015-12-25 20.59.39.png

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

  • true
  • input

ただもう一つ落とし穴が

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

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

スクリーンショット 2015-12-25 21.37.26.png

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

ここまでのまとめ

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

Repository上のCRLFLFに変換する方法

さて、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の改行をそのままにするinputfalseの設定にしておいてから、working directoryにチェックアウトをしてあげる必要があるようです。
※ただ、その際、working directoryを一度削除しないと、同期が取れないようです。

712
597
11

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
712
597

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?