【Git】改行コードを正しく管理する方法をわかりやすく解説

はじめに

git でソースコードやテキストファイルを管理していると、改行コードにまつわる問題に悩まされることがあります。
Windows と Mac/Linux では改行の扱いが異なるため、チーム開発や複数の環境でファイルを共同編集するときに混乱するかもしれません。

とくに初心者の方にとっては、目に見えない改行の違いによって生じるバグやコンフリクトは厄介ではないでしょうか。
今回は、改行コードを正しく理解し、git で管理する方法について分かりやすくまとめていきます。

この記事を読むとわかること

• 改行コードの基本的な仕組み
• git が改行コードをどのように扱うか
• 実際の設定や .gitattributes ファイルの使い方
• Windows と Mac/Linux の改行コードの違い
• 改行コードに関するよくあるトラブルと対策

改行コードとは何か

改行コードはテキストファイルでの「行の区切り」を表すものです。
コンピュータにとっては、改行も文字の一種なので目に見えない文字が挿入されているようなイメージです。
環境によって改行コードの種類が異なるため、異なる OS 間でファイルを共有すると不具合が起こりやすいのです。

主な改行コードの種類

• LF (Line Feed)
• CR (Carriage Return)
• CRLF (Carriage Return + Line Feed)

Mac/Linux 系の環境では LF、Windows では CRLF が一般的です。
古い Mac OS では CR が使われていた時期もありましたが、現在はほとんど見かけません。

なぜ改行コードの違いで問題が起こる？

改行コードの種類が異なると、ファイルの中身が同じに見えても実際はバイナリレベルで違う場合があります。
その結果、不要な差分が出たり、ファイルが壊れたように見えたりすることがあるのです。

もし複数のメンバーがそれぞれの環境でファイルを編集し、改行コードがバラバラになってしまうと、思わぬバグやコンフリクトを引き起こします。

git と改行コード

git は改行コードの扱いをある程度自動でサポートしていますが、設定を誤ると期待しない変換が行われる場合があります。
初心者の方は、自分のローカル環境でファイルを編集してコミットするときに「知らない間に改行コードが変えられていた」というケースに戸惑うことが多いです。

git が改行コードをどう管理するか

git は基本的にテキストファイルを扱う際、改行コードを統一して扱うことを推奨しています。
これによって OS による違いを吸収しやすくし、差分管理を快適にするのが狙いです。

ローカル環境の設定によっては、コミット時やチェックアウト時に自動で改行コードを変換する機能があります。
この機能をうまく活用しないと、ファイルの中身が意図せず変化してしまうことがあるため注意が必要です。

core.autocrlf の設定方法と選択肢

git の設定として有名なのが core.autocrlf オプションです。
このオプションの値を変えることで、コミットやチェックアウトの際に改行コードをどう扱うかを制御できます。

以下は一例です。

コピー
# Windows ユーザーの場合、LF を CRLF に変換する
git config --global core.autocrlf true

# Mac/Linux ユーザーの場合、自動変換を無効化する
git config --global core.autocrlf false

# 途中で変換するが、コミット時には LF に揃える
git config --global core.autocrlf input

true

チェックアウト時に LF を CRLF に変換して、コミット時に CRLF を LF に戻します。
主に Windows で作業し、リポジトリでは LF を統一したいときに使うケースです。

false

一切の変換を行いません。
Mac/Linux 環境など、もともと LF が使用される環境であればこのモードにしておくと安全です。

input

チェックアウト時には何もしませんが、コミットするときに CRLF を LF に変換します。
Windows だけどリポジトリは LF に統一したい、というときに便利です。

実務での活用事例

たとえば大規模なチーム開発で Windows ユーザーと Mac/Linux ユーザーが混在している場合には、リポジトリの基準を LF に統一しておくとトラブルを最小限にできます。
Mac/Linux のメンバーは core.autocrlf を false、Windows のメンバーは true か input を選ぶなど、ルールを決めておくと良いでしょう。

このように、改行コードの扱いを明確に決めることで、不要な差分やコンフリクトを減らし、ソースコード管理を効率的に進めることができます。

.gitattributes を活用した改行コードの管理

より細かい制御が必要なときには、.gitattributes ファイルを使うのが便利です。
プロジェクト直下に .gitattributes を置き、特定のファイル拡張子に対して改行コードのルールを指定できます。

.gitattributes ファイルの基本構文

例として、以下のような設定を行うと、特定のファイルだけ LF に統一し、ほかは変換しないという指定ができます。

コピー
# 改行コードを自動で修正
*.txt text eol=lf
*.sh  text eol=lf

# イメージファイルなどバイナリは対象外
*.png binary
*.jpg binary

• text eol=lf と書くと、その拡張子のファイルはコミット時に LF へ変換されます。
• binary と書くと、改行コードの自動変換は行われず、そのままのバイナリデータとして扱われます。

なぜ .gitattributes が便利なのか

core.autocrlf の設定は、開発者のローカル環境に依存します。一方 .gitattributes はリポジトリに含まれているため、チーム全体で統一されたルールを簡単に共有しやすいのです。
その結果、どのメンバーがどんな OS を使っていても、ファイルの改行コードが混乱するリスクを抑えられます。

また、大規模なプロジェクトでは拡張子ごとに改行コードを厳密に管理したいケースがあるかもしれません。
このような場合にも .gitattributes で柔軟に制御できるのが大きなメリットと言えるでしょう。

OSごとの改行コードの違い

改行コードは、OS が異なると以下のように扱いが違います。

Windows の CRLF

Windows では行末を表すのに CR (Carriage Return) と LF (Line Feed) の 2 文字を使用します。 これは古いタイプライターの動作を模した由来があると言われています。
Windows で作成されたテキストファイルを Mac/Linux で開くと、意図しない記号が表示されることがあります。

Mac/Linux の LF

Mac と Linux では主に LF のみを使います。
シンプルな構造なので、バージョン管理システムでも LF を共通化していることが多いです。
Windows で LF のファイルを開くと、テキストエディタによっては見た目は問題なく表示される場合もありますが、改行コードを自動変換する機能を持つエディタもあります。

改行コードをそろえるメリット

• コードレビューや差分管理がしやすい
• バグや文字化けのリスクを下げられる
• プロジェクト全体での統一感が出る

複数の OS が混在する環境では、意識的に改行コードを統一する必要があるでしょう。

よくあるトラブル事例

改行コードの差異が原因で発生しがちなトラブルをいくつか紹介します。
初心者の方は、こういった状況を一度は経験したことがあるかもしれません。

不必要な差分の発生

Windows ユーザーが CRLF のファイルをコミットし、Linux ユーザーが LF で上書きすると、同じ内容なのにすべての行が変更されたことになってしまう場合があります。
これにより、履歴の比較が困難になり、生産性が落ちることが多いです。

シェルスクリプトが動かない

Mac/Linux 環境で作成したシェルスクリプトに CRLF が混ざっていると、余計な文字が含まれていると判断されて実行できないことがあります。
改行コードを正しく LF に揃えておけば、こういったトラブルを回避できます。

コンフリクトの増加

改行コードが一致していないと、差分認識がずれて不必要なコンフリクトを招くことがあります。
せっかく同じところを編集していないはずなのに、コンフリクト解消に手間取る場合があるのです。

まとめ

改行コードは初心者にとって見えづらいトピックですが、git を使う以上は避けて通れません。
Windows と Mac/Linux で違いがあるため、チーム開発では早めに方針を決めておくことが大切です。

git の core.autocrlf を正しく設定したり、.gitattributes を活用したりすることで、改行コード問題による混乱を最小限に抑えることができます。
特にプロジェクトの初期段階であれば、ファイルが増える前にルールをしっかり整備しておくと安心でしょう。

一度改行コードのルールを決めておくと、あとから発生するトラブルが格段に減ります。
これを機に、改行コードの基本と git での管理方法をしっかり押さえておきましょう。