SourceTreeの比較プレビューがうまく動いていないことってありますよね。ファイルをちょこちょこ修正しただけなのに、比較プレビューをみると全行変更扱いになってたりして、「なんで?」ってなります。
今までは原因を突き止めようとせず、とりあえず流してました。
特に重要なファイルでこの現象が発生していたわけでもないので、腰をすえてさがさなかったんですねー。
さて、本日ふと時間が空いたので、腰を据えて探してみました。いやー、調べれば結構あっさり解決するもんです。
ソース比較の不具合の原因
結論から言えば「改行コード」が原因でした。
ファイルの改行コードが【CR】で設定されていたので、SourceTreeのテキスト比較機能がうまく動作していませんでした。
改行コードを【CR】→【LF】に変更すればあ~ら不思議、ちゃんと比較できるようになりました。基本的には、【LF】もしくは【CR+LF】のどちらかです。【CR】は割りと古いMacで使用されていた改行コードのようです。
よく観察してみるとエディタで開いた時とSourceTreeの比較プレビューで見た際は行数の数字が全然違っていました。
改行コードとは?
コンピュータに改行を認識させるために用いるのが改行コードです。改行コードは以下の表のようにOSによって違います。
OS | 改行コード |
unix | LF |
Mac (特にOS 9以前) | CR |
Windows | CR+LF |
改行コードが異なるとCGIスクリプトなどは正しく改行コードを認識できず、不具合の原因になることが多いと言われています。
ちなみに改行コードの意味は
LF・・・Line Feed(ラインフィード)
カーソルを新しい行に移動することです。改行という意味です。
CR・・・Carriage Return(キャリッジリターン)
カーソルを左端の位置に戻すことです。復帰という意味です。
CR+LF
左端にカーソルを戻して改行することです。前述のCRとLFと合わせたものです。
ぼくはSublime Text 3 を使っているのですが、改行コードを表示する設定にしていなかったので、これを機に表示設定に切り替えました。
まとめ
普段は全然意識しない改行コードですが、頭の片隅に置いておかないと改行コードが原因でハマるときには、無駄に時間ばかりが過ぎてしまいます。イレギュラーな不具合が起きた時には、原因のひとつとして探ってみるのもいいかもしれません。