🙏 Please Add .gitattributes To Your Git Repository

What Is .gitattributes?

The .gitattributes file allows you to specify the files and paths attributes that should be used by git when performing git actions, such as git commit, etc.

In other words git automatically saves the file according to the attributes specified, every time a file is created or saved.

One of these attributes is the eol (end of line) and is used to configure the line endings for a file. This article will now dive deeper into how to configure the line endings, so every developer uses the same value when using different machines / OSes across the repository.

Why .gitattributes (Developers At War ⚔️)?

Not all developers are the same, just because you develop on a Windows machine using Visual Studio Code, don't expect the next pull request to have been implemented using the same dev environment (MacOS machine using Sublime Text 2).

As mentioned above the developers are using different OSes (Windows and MacOS) the default for the line ending will differ. On the Windows machine the default for the line ending is a Carriage Return Line Feed (CRLF), whereas on Linux/MacOS it's a Line Feed (LF).

To the naked eye the content will look the same, so why should we bother???

Well, if you have prettier enabled and the endOfLine property is set to lf.

{
  "endOfLine": "lf"
}

On the Windows machine the developer will encounter linting issues from prettier, like those below.

Code File With Prettier Linting Errors

This is where .gitattributes comes to the rescue and saves the day 🦸!

New Repository (Repo)

To add the .gitattributes to the repo first you need to create a file called .gitattributes into the root folder for the repo.

Below is an example of the contents for the .gitattributes file.

*.js    eol=lf
*.jsx   eol=lf
*.json  eol=lf

Commit this file to the repo and push your changes to the server.

git add .
git commit -m "Added .gitattributes to repo"
git push

Now when anyone gets the code from the repo the default correct line ending will be used automatically via git, when creating and modifying the files.

Add to Existing Git Repository (Repo)

Follow the steps mentioned in the New Repository (Repo) steps to create the .gitattributes file. Once the file has been pushed to the git server then make sure that your local repo is clean and has nothing to commit. Use git status to determine whether your repo is clean.

git status

Note: If you still have files to push or commit, please make sure that these actions are performed or the files are stashed before you perform the next commands.

GitAttributes Reset

git rm --cached -r .
git reset --hard

The above commands will now update the files for the repo using the newly defined line ending as specified in the .gitattributes.

Any changes or new changes will automatically use the line endings specified for that file type.

Next step is to inform any team mate or collaborator, to run the GitAttributes Reset commands.

Now prettier won't complain about CR and all developers can now live in peace! ☮️

Code File With No Prettier Linting Errors

Comments

[MuhireIghor]

This is a helpful tool at all

[roadpepe]

If you are lazy and want to quickly add a .gitattributes to your project but don't want to create one from scratch, you could use github.com/alexkaratarakis/gitattr... for a template. It's quick, simple and supports most common languages.

[Ashutosh Singh Parmar]

@Carl where can we find a comprehensive lists of these attributes usable inside .gitattributes?

[Ashutosh Singh Parmar]

True... notepad is best for temporary things..

[Dr. Derek Austin 🥳]

Haha I take meeting notes in Notepad all the time, though I'm often terrified the power will go out lol.

FWIW I changed a file to LF line endings in VS Code and edited it in Notepad without problems...

[kerami]

Thanks for this post! :)

[Viktor]

What's the difference between CR LF, LF and CR? As far as I know all three do the same these days.
To sum it up:

1. You don't see the character
2. The output is the same (file size negligently bigger in case of CRLF)
3. No added value of using one over the other.

I think this should be ignored in prettier.

Focus on something that actually has a visible effect, don't try to fix something for the sake of OCD satisfaction.

[Mohammad]

Why there is --cached in git rm as it makes no difference in the final result?
Am I missing some thing?

[Andrew Lane]

Should your

git rm --cached -r

command be this instead?

git rm --cached -r .

[Carl Saunders]

Yep, good spot. I'll change it now.

[AngularNodeJS 🚀]

This is pretty good advice. I have been using a combination of editorconfig files with pre-commit hooks to run linting and formatting which enforces 'eol'.

Your solution is more elegant. Reading the github reference on this, it might be better to do it this way, using auto.

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

*.js    text
*.jsx   text
*.json  text

This way, whatever OS you are no, git will decide the correct 'eol' to apply for you.

[Sean van Zuidam]

For commen formatting rules we use the .editorconfig

[Edwin Klesman]

Never knew that... Now I do!

Thanks for this post!

[Xandor Schiefer]

Another great use-case for .gitattributes is to mark certain text files as binary. I do this with lock files and other machine-generated files which should be committed to the repo.

This way, when looking through diffs in the history, the staging area, or even on hosted Git platforms, these files no longer add to the noise.

[Patryk Bernasiewicz]

We don't use linters at work, so we don't have problems with cross-platform line-ending issues.

[Lajos Koszti]

Why don't you just configure that editor|IDE?

[Justin K.]

this may take longer than creating a single file with maybe 1 line :)

[george udosen]

The git command 'git rm --cached -r' does nothing but show me usage options! So which file(s) are we removing from the cache

[Carl Saunders]

I've fixed the git command, as it should of been.

git rm --cached -r .