In one of the previous posts at here, we discussed how we can use git aliases to improve the git experience. However, the personalization is not limited to setup of few command aliases. In this post, we’ll discuss how we can modify git configuration for better productivity and experience further. You will mostly need to do these changes per machine only once and they’ll stick around between upgrades. However, you can modify them later at any point, in case you want to.

Configuration Scopes

Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables are stored in usually 3 places:

System – Applied to all users in your computer. It is stored at /etc/gitconfig in the linux versions. If you pass the option ––system to git config, it reads and writes from this specifically. On Windows OS, this file is relative to MSys root, which is wherever you decide to install Git.
Global – Applied to your user account only, but all repositories. It is stored at ~/.gitconfig or ~/.config/git/config file. If you pass the option ––global, it reads and writes from this file.
Local – Applied to the current repository only. It is stored as .git/config file.

Each level overrides the values from the previous level, so values at repository level overrides values specified at global level.

Listing Current Configuration

You can run below command to list all current configuration values:

git config -l

It lists combined results from all scopes. If you specify a scope like ––local, it will list values from that scope only.

Configure Identity

One of the first things you should do is to setup your username and email address. This is because, this information is captured as part of every commit and baked into the commit details. You can easily set this up by running:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

If you want to override this with a different name or email address for specific repositories, you can run above commands again without the ––global option, when you are in that project.

Configure Text Editor

It is also a good idea to setup default text editor that will be used when Git needs us to type in a message. By default, Git uses whatever you’ve set as your default text editor via one of the shell environment variables VISUAL or EDITOR, or else falls back to the vi editor to create and edit your commit and tag messages. It can be controlled using:

$ git config --global core.editor emacs

where emacs is the name of the editor. You can replace this editor of your choice.

Configure Commit Template

Commit templates can be used as an reminder of the proper format and style when creating a commit message. This helps in implementing organizational policies around source code. For example, an commit template can look like:

[Ticket X] Subject line (try to keep under 50 characters)

Multi-line description of commit,
feel free to be detailed.

To tell Git to use it as the default message that appears in your editor when you run git commit, set the commit.template configuration value:

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

Then, your editor will open to something like this for your placeholder commit message when you commit:

Configure Pager Settings

This setting determines which pager is used when Git pages output such as log and diff. You can set it to more or to your favorite pager (by default, it’s less), or you can turn it off by setting it to a blank string:

$ git config --global core.pager ''

If you run that, Git will page the entire output of all commands, no matter how long they are.

Always Excludes Certain Files

Sometimes, rather than ignoring files at repository level, you always wanted to ignore certain files. This is also because you’ll be most likely working with couple of the editors like Visual Studio or Eclipse or something else. Or it may be just .retry or .swp files. This setting lets you write a kind of global .gitignore file. If you create a ~/.gitignore.txt file with these contents:

~
*.swp
*.retry
.vs/

and run:

$ git config --global core.excludesfile ~/.gitignore.txt

Git will never again bother you about those files.

Autocorrect Commands

Many times, if you do a typo, git will complain about it but do not proceed further. For example:

If you set help.autocorrect to 1 by using below command:

$ git config --global help.autocorrect 1

Git will actually run this command for you:

The duration in which auto-correct is invoked, can be adjusted. So 1 in above command represents 0.1 seconds. If you specify 100, it means 10 seconds.

External Merge and Diff Tools

You can set up a graphical merge-conflict-resolution tool instead of having to resolve conflicts manually. Same goes for showing git diff. If you like to edit your code in an IDE like Visual Studio or Eclipse, you would like to set it to that. Git also comes preset to use a number of other merge-resolution tools without your having to set up the required configuration. To see a list of the tools it supports out of the box, try this:

$ git config git mergetool --tool-help

Configure Formatting for Line Endings

If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character.

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true — this converts LF endings into CRLF when you check out code.

However, I would suggest to leave this setting unchanged and instead use .gitattributes file. Most of the time, this is as simple as creating a file named .gitattributes at the root of your repository that contains one line:

*text=auto

With this set, Windows users will have text files converted from Windows style line endings (\r\n) to Unix style line endings (\n) when they’re added to the repository. Also, it is controlled at the repository level rather than at the developer’s machine level.

There are many other settings, which may be of some importance to you. Please check the official documentation here for same.