SourceTreeの比較プレビューがおかしいのは、改行コードのせいだったりした件

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 を使っているのですが、改行コードを表示する設定にしていなかったので、これを機に表示設定に切り替えました。

 

まとめ

普段は全然意識しない改行コードですが、頭の片隅に置いておかないと改行コードが原因でハマるときには、無駄に時間ばかりが過ぎてしまいます。イレギュラーな不具合が起きた時には、原因のひとつとして探ってみるのもいいかもしれません。

 

上部へスクロール