.gitattributes Generator

Generate a .gitattributes file by ticking the policies you want. Normalize line endings with text=auto, force LF for scripts and CRLF for Windows files, mark common binary types, track large assets with Git LFS, tune GitHub Linguist language stats, set per-language diff drivers, and add export-ignore rules for release archives. The file builds live and runs entirely in your browser.

How to use the .gitattributes Generator

Tick the policies you want and the file assembles itself. The single most useful line is line-ending normalization (* text=auto): it tells Git to detect text files and store them with LF in the repository while checking them out with the platform's native endings, which ends the endless "the whole file changed" diffs that happen when contributors are on different operating systems. Layer Force LF on top to pin scripts and source that must stay LF even on Windows (shell scripts break with CRLF), and Force CRLF for the handful of Windows-only files that need it.

Mark binaries tells Git not to try line-ending conversion or text diffs on images, fonts, archives and media — treating them as opaque. Git LFS goes further, storing large or frequently-changing binaries outside the main history (you must have git lfs install set up for these lines to take effect). The Linguist block keeps GitHub's language bar honest by excluding dist/, minified files and vendored code from the statistics, and export-ignore strips development files from the tarballs produced by git archive. Copy the result to a file named .gitattributes in your repository root; for the normalization to apply to existing files, run git add --renormalize . once after committing it.

What .gitattributes controls

.gitattributes is a per-path settings file that tells Git how to treat matching files — independently of any individual developer's local configuration. Where .gitignore decides what Git tracks, .gitattributes decides how Git handles what it tracks: whether a file is text or binary, how its line endings are normalized, which diff and merge drivers apply, whether it goes through Git LFS, and how tooling like GitHub Linguist should classify it. Because the rules live in the repository and are committed, they apply consistently to everyone who clones it, which is exactly what you want for project-wide policy.

The headline feature is line-ending normalization. Windows tools default to CRLF and Unix tools to LF, so without a policy the same file can appear entirely changed depending on who touched it last, polluting diffs and causing spurious merge conflicts. The directive * text=auto instructs Git to store a canonical LF version in the repository and convert on checkout, while explicit text eol=lf or eol=crlf rules pin specific file types that must keep one ending — shell scripts and Makefiles need LF; some Windows files need CRLF. Marking files binary (shorthand for -text -diff) prevents any conversion or text diffing of images and other non-text content.

Beyond endings, .gitattributes drives several quality-of-life behaviours. Git LFS uses filter, diff and merge attributes to swap large binaries for lightweight pointers, keeping the repository fast to clone. diff drivers give language-aware hunk headers so a diff shows the enclosing function or section. linguist-generated, linguist-vendored and linguist-documentation stop GitHub from counting build output and third-party code in the language breakdown. And export-ignore omits development-only paths from git archive exports. None of these require special tooling to write — they're just lines of text — which is why generating a correct, conventional file and committing it is the whole job.

Common use cases

  • Cross-platform teams. Normalize line endings so Windows and Unix contributors stop producing whole-file diffs.
  • Large assets. Route design files, video and binaries through Git LFS to keep clones fast.
  • Cleaner language stats. Exclude generated and vendored code from GitHub's Linguist breakdown.
  • Release tarballs. Strip tests, CI and docs from git archive output with export-ignore.

Frequently asked questions

What is the difference between .gitattributes and .gitignore?
.gitignore decides which files Git tracks at all; .gitattributes decides how Git handles the files it does track — line endings, text/binary classification, diff and merge drivers, Git LFS routing, and Linguist hints. They solve different problems and are often used together.

I added text=auto but existing files still show CRLF diffs. Why?
Attributes apply going forward; existing files already committed keep their stored endings until renormalized. After committing the .gitattributes file, run "git add --renormalize ." and commit the result. That rewrites the working files to the canonical LF storage so future diffs are clean.

Do the Git LFS lines work on their own?
They declare which paths should use LFS, but LFS itself must be installed and initialised: run "git lfs install" once per machine, and ensure the server supports LFS. Without that setup the filter=lfs lines are inert and files are stored normally.

What does marking a file "binary" actually do?
binary is shorthand for "-text -diff": Git will not perform line-ending conversion and will not attempt a textual diff, treating the file as opaque bytes. Use it for images, fonts, compiled artifacts and archives so they are never corrupted by EOL normalization or shown as unreadable diffs.

Will linguist-generated hide files from GitHub?
No — the files are still in the repository and viewable. linguist-generated only excludes them from the language statistics bar and collapses them by default in diffs. Use linguist-vendored for third-party code and linguist-documentation for docs to keep the language breakdown representative of your own code.
Embed this tool on your site

Free to embed, no attribution required (but appreciated). Paste this where you want the tool to appear: