gitattributes/gitattributes: A Community Template Library for .gitattributes Files

What the Repository Contains and Why .gitattributes Matters

A .gitattributes file sits at the root of a Git repository and tells Git how to handle specific file types. It controls three main concerns: line ending normalization between Windows (CRLF) and Unix (LF) systems, how to classify files as binary to prevent corruption during merges, and how GitHub's Linguist counts repository language statistics.

Without a .gitattributes file, line ending behavior depends on the `core.autocrlf` setting in each developer's local Git configuration. On cross-platform teams, this causes noise in diffs and occasionally corrupts binary files treated as text. A committed .gitattributes file removes that ambiguity and makes behavior consistent regardless of individual workstation settings.

The gitattributes/gitattributes repository addresses the same gap for .gitattributes that the github/gitignore repository addresses for .gitignore files. The README explicitly draws this parallel. The collection covers languages including ActionScript, Ada, C++, C#, Delphi, Elixir, Fortran, Go, Java, Lua, Matlab, Objective-C, PHP, Pascal, Perl, PowerShell, Python, R, Rails, Rust, Swift, Unity, Vim, and several web-oriented configurations, along with a Global/ directory for tool-specific overrides and a Community/ directory for user-contributed additions.

Template Organization and the Generator Tool

Each template in the repository is a standalone file named after its language or framework, for example Go.gitattributes or Unity.gitattributes. The intention is that you pick the files relevant to your stack and combine them into a single .gitattributes for your repository.

A file named Common.gitattributes contains general exclusions that apply to any project regardless of language. The README recommends including it alongside any language-specific templates.

For projects that do not want to assemble templates manually, the README points to a web-based generator at richienb.github.io/gitattributes-generator. This tool reads the template files from the repository and lets you select the languages and frameworks you need, then assembles a combined .gitattributes file for download.

The flags used in templates cover the most common scenarios. The `text=auto` attribute tells Git to detect whether a file is text or binary and normalize line endings automatically. Setting `eol=lf` or `eol=crlf` forces a specific ending for a named file pattern. Marking a file as `binary` prevents any normalization and disables text diffing. The `filter=lfs diff=lfs merge=lfs` combination, used in some templates such as Unity.gitattributes, marks large binary assets for Git LFS tracking.

GitHub Linguist Overrides in the Templates

Several templates include attributes that alter how GitHub counts language statistics for a repository. These are passed to GitHub's Linguist tool, which classifies files for the language breakdown shown on repository pages.

Common overrides include `linguist-generated=true` for files that should not count toward language statistics because they are auto-generated, `linguist-vendored=true` for third-party code committed to the repository, and `linguist-language=` for files that Linguist misidentifies.

The Linguist documentation that governs these overrides is linked from the README as the GitHub-specific grammar reference. Engineers who need to suppress a generated file from affecting language statistics, or who want to correct the detected language for a domain-specific format, can use these attributes without writing custom Linguist rules.

The Web.gitattributes template includes entries for common front-end file types. The Markdown.gitattributes template handles .md files explicitly. DyalogAPL.gitattributes covers the less common APL variant used in some data-science toolchains.

Running the CI Verification Script

The repository includes a checked-in shell script at the root, check.sh, that verifies whether every file in a repository has a corresponding .gitattributes rule. The README provides an inline version of the core check:

missing_attributes=$(git ls-files | git check-attr -a --stdin | grep 'text: auto' || printf '\n')

if [ -n "$missing_attributes" ]; then
  printf '%s\n%s\n' '.gitattributes rule missing for the following files:' "$missing_attributes"
else
  printf '%s\n' 'All files have a corresponding rule in .gitattributes'
fi

This script identifies files that match the `text: auto` fallback, meaning Git is guessing at their handling rather than following an explicit rule. Files reported here should be given explicit attributes in .gitattributes.

The checked-in check.sh extends this with additional options. Run `./check.sh --help` to see the available flags. Adding this check to a CI pipeline catches regressions when new file types are introduced to the repository without a corresponding .gitattributes entry.

Limitations and When This Repository Is Not Enough

The repository covers a fixed set of languages and frameworks. Projects using less common languages or unusual binary formats will not find a ready-made template and must write their own entries. The README does not document how to determine which attributes are appropriate for a new file type; that requires reading the official gitattributes(5) man page.

For Git LFS specifically, the templates mark files for LFS tracking but do not install Git LFS itself or handle the server-side configuration required to actually store large files. An engineer who copies the Unity.gitattributes template expecting LFS to work automatically will encounter errors until `git lfs install` has been run and the LFS endpoint is configured.

The official Git documentation at git-scm.com/docs/gitattributes serves as the primary reference when templates do not cover a specific case. That reference describes the full attribute grammar, including custom merge drivers and diff tools, which are outside the scope of this template collection.

The last push to the repository was on 2026-07-22, which indicates recent activity. The project has no GitHub releases and no versioned changelog, so there is no structured way to track what changed between template updates.

Contributing: The One-File-Per-Commit Rule

The README specifies one rule for contributors: modify only one file per commit. This policy exists to simplify merging. Because many pull requests touch a single language template, keeping each change isolated makes conflict resolution straightforward and keeps the review scope narrow.

Contributions are submitted through forks and pull requests. The repository links to GitHub's standard fork and pull request documentation rather than maintaining its own contributing guide. The Community/ directory in the top-level structure holds contributions that did not fit the main template list.

The project is MIT licensed, which means templates can be copied into other projects, included in generators and tooling, or redistributed without restriction. This makes the collection a practical dependency for build tools or project scaffolding systems that generate .gitattributes files automatically.

Editorial conclusion

This repository is the right starting point for any project that needs a vetted .gitattributes file and does not want to write one from scratch. The MIT license permits unrestricted reuse. Engineers maintaining polyglot repositories should combine the per-language files with Common.gitattributes and then run the included check.sh to verify full coverage before merging. Solo developers working in a single well-covered language can copy the relevant template directly without further configuration.

Frequently asked questions

Official sources

1. gitattributes/gitattributes on GitHub
2. Issues
3. License: MIT
4. README