⭐ Introduction

If you work on projects across different operating systems—Windows, macOS, Linux, GitHub Codespaces, or VS Code—you’ve probably seen this warning:

LF will be replaced by CRLF

Or the opposite:

CRLF will be replaced by LF

These line-ending differences cause:

• Annoying Git warnings
• Unwanted file changes
• Merge conflicts
• Failing scripts or builds
• Confusion for beginners

The solution is simple: use a .gitattributes file to make Git follow one consistent end-of-line format across your project.

This post explains what line endings are, why they cause problems, and how to fix everything with one small file.

---

🧠 What Are Line Endings?

Different operating systems use different characters to mark the end of a line in a text file:

Operating System	Line Ending	Symbol
Windows	CRLF	\r\n
macOS / Linux	LF	\n

This means:

• A file created on Windows uses CRLF
• A file created on macOS/Linux uses LF

Git tracks changes line by line, so mismatched endings lead to unnecessary diffs and team headaches.

---

⚠️ Why Line Endings Cause Git Problems

Without a consistent setting:

• Git thinks every line changed
• Files appear modified even when you only saved them
• Team members keep overwriting each other
• GitHub Codespaces and VS Code auto-convert endings
• CI/CD pipelines may fail scripts

So the fix is to force Git to use one format for your project.

---

✔ The Recommended Standard: Use LF Everywhere

Most teams and open-source projects use:

• LF for code
• Automatic conversion when developers commit

That way:

• macOS/Linux users get natural LF
• Windows users still see CRLF locally if they want
• Git stores clean LF in the repository

---

📁 The Simple Fix: Add a .gitattributes File

Create a file named:

.gitattributes

Put it in the root of your repository.

Add:

* text=auto eol=lf

What this means:

• * → apply to all files
• text=auto → Git detects text files automatically
• eol=lf → always normalize to LF in the repository

This single rule solves 95% of line-ending problems.

---

🧪 Example: Handling Specific File Types

If you want more control:

*.sh     text eol=lf
*.js     text eol=lf
*.ts     text eol=lf
*.py     text eol=lf
*.html   text eol=lf
*.css    text eol=lf

Force binary files to stay untouched:

*.png    binary
*.jpg    binary
*.pdf    binary
*.zip    binary

Windows batch files? Use CRLF:

*.bat    text eol=crlf
*.cmd    text eol=crlf

---

🔁 Apply the Fix to Existing Files

After adding .gitattributes, run:

git add --renormalize .
git commit -m "Normalize line endings"

This updates all existing files to follow the new rules.

---

💻 How GitHub Codespaces Handles Line Endings

Codespaces uses Linux containers, so LF is the default.

Using .gitattributes ensures:

• Windows developers get consistent behavior
• Codespaces always saves LF
• No more confusing diffs between devices

Your project becomes platform-independent.

---

👍 Best Practices

• Always include a .gitattributes file in every new repo
• Use LF (eol=lf) as the universal standard
• Explicitly set binary file types
• Normalize your repository once
• Keep settings simple
• Encourage your team to use .gitattributes instead of local Git settings

---

🎉 Conclusion

Line-ending issues are one of the most common beginner frustrations in Git, but the fix is surprisingly simple. By adding a .gitattributes file, you ensure:

• Cleaner Git history
• No more pointless diffs
• No merge conflicts due to CRLF/LF
• Consistent behavior across Windows, macOS, Linux, and Codespaces

With one small file, your entire team gets a smooth, predictable experience.