Introduction

The best Git strategy for line endings is to make the repository policy explicit instead of relying on every developer's local defaults. In practice, that means normalizing text files with .gitattributes, letting Git distinguish text from binary, and avoiding ad hoc CRLF conversion surprises.

The Core Problem

Windows commonly uses CRLF line endings, while Linux and macOS commonly use LF. If a repository does not define a policy, collaborators can keep rewriting the same files with different endings, producing noisy diffs and unnecessary merge conflicts.

Git can help, but only if the team chooses a consistent approach.

Prefer Repository-Level Rules

The strongest strategy is to declare line-ending behavior in .gitattributes:

1* text=auto
2*.sh text eol=lf
3*.cs text eol=lf
4*.bat text eol=crlf
5*.png binary
6*.jpg binary

This does three important things:

1. normalizes text files in the repository
2. forces specific files to LF or CRLF where appropriate
3. protects binary files from conversion

That is better than depending only on core.autocrlf, because .gitattributes travels with the repository and applies consistently for everyone.

What to Do with core.autocrlf

If .gitattributes is defined well, many teams keep local Git config simple and let attributes drive behavior. The exact local setting is less important than avoiding conflicting personal setups across contributors.

Typical patterns are:

• Windows developers often use core.autocrlf=false when the repo already defines attributes clearly
• macOS or Linux developers often use core.autocrlf=input or false

The key idea is not "one magic global value for everyone." The key idea is "the repository owns the policy."

Renormalizing an Existing Repository

After adding .gitattributes, you often need to renormalize:

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

That makes the repository index consistent with the new rules. Without this step, old mixed line endings can linger.

Why Not Just Force CRLF Everywhere

Because many tools, shells, and CI environments expect LF-friendly text files. Scripts such as shell scripts, container config, and many language toolchains behave more predictably when the repository stores normalized LF text.

Then, if a local checkout needs CRLF for a specific file type, .gitattributes can express that explicitly.

A Practical Team Policy

A good cross-platform rule set is:

• store source files in LF in the repository
• explicitly mark Windows-only script types as CRLF if needed
• mark binary assets as binary
• commit a .gitattributes file early

That keeps the index stable and the checkout behavior understandable. It also makes onboarding easier because contributors do not need to reverse-engineer the repository's line-ending expectations from old commits and scattered local config. That kind of predictability matters a lot in mixed Windows, macOS, and Linux teams.

Common Pitfalls

The biggest mistake is relying on personal core.autocrlf values alone. That creates repository behavior by accident instead of by policy.

Another mistake is forgetting binary files. Git should not attempt line-ending normalization on images, archives, or other opaque data.

A third issue is introducing .gitattributes but never renormalizing the existing tree. Then the repository still contains inconsistent historical endings even though the policy file exists.

Summary

• Put the line-ending policy in .gitattributes, not only in developer machine settings.
• Normalize text files explicitly and mark binary files as binary.
• Store most source files as LF in the repository.
• Use file-specific exceptions for Windows-oriented scripts when necessary.
• After defining the policy, renormalize the repository so the index matches it.