Three Git Configurations that Should Be the Default

Recently, I started to customize my Git configuration to fit my workflow. I’ve found a few configurations that should be the default for anyone who installs Git:


git config --global pull.rebase true
git config --global fetch.prune true
git config --global diff.colorMoved zebra

I’ve had these in place for the past few months, and I’d encourage you to apply them right now. However, in case you need to see the benefits before blindly trusting me, I’ll give a quick overview of how each configuration has helped my workflow.

Pull with Rebase

This configuration will make pull commands rebase instead of merge:


git config --global pull.rebase true

When there are remote changes that are not on your local branch, they need to be resolved. The default Git behavior is merging, which will create a new commit on your local branch that resolves those changes.

This configuration switches that behavior to the rebasing strategy. With rebasing, new commits will be created for the changes on your local branch that start after the changes on the remote branch. To learn more, I’d suggest Git Merging vs. Rebasing: The Beginner’s Guide.

Working with a pair? Rebasing when pulling makes the branch history cleaner. And you can avoid merge commits when pulling in your pair’s work from remote to your local branch.

Prune on Fetch

This configuration will automatically clean Git objects in your repository locally whenever you fetch changes from remote.


git config --global fetch.prune true

If this configuration is set, running git fetch will also run git remote prune afterwards. git remote prune will delete inaccessible Git objects in your local repository that aren’t on remote. Deleting branches on remote but not locally will generate these inaccessible Git objects.

Having this option enabled minimizes the number of branches I have on my local machine. Any autocomplete feature that uses this list of branches is much easier to use with limited branches hanging around.

Differentiate Moved Lines

This configuration adds extra colors when running git diff to show blocks of lines that remain unchanged but have moved in the file.


git config --global diff.colorMoved zebra

By default, the diff expresses the changes as additions and deletions, with green and red denoting the operation done to a line. The additional colors help differentiate actual changes and lines moving around due to those changes.

Here’s an example of a diff created by moving a block of code in a file:

Git Zebra Diff

Since turning on this configuration, I’ve found diffs much easier to read. I’m able to focus on the lines of code that actually changed and brush over blocks of code that are just moving around. Diffs are much more meaningful when I have a way to focus on what really changes.

More Potential Defaults?

I could spend more time trying out different configurations, but these have served me well so far. I would highly recommend them to anyone using Git.

Are there any Git configurations you’d recommend? Leave a comment below, and I’ll check them out!

Conversation
  • Dylan says:

    I never leave home without: rebase.autostash and rebase.autoSquash set to true!

  • Jakob says:

    I used to fetch and rebase by hand to prevent the conflicts, turns out I don’t need to do that anymore. Thanks!

  • Nuno André says:

    I use to set “git config –global push.default simple” to push only the current branch.

  • majudhu says:

    pull with rebase can lead to loss of history or even code on merge conflicts, unless one is quite skilled with resolving merge conflicts correctly

    • Phil Hord says:

      Yes, you shouldn’t enable pull.rebase unless you are comfortable using rebase. That said, it’s not much different from the default of merging with pull. You can get conflicts in either case. The difference is that with a merge conflict you can “undo” with `git reset –hard HEAD` and with a rebase conflict you use `git rebase –abort`.

      Lose history? I guess so, but its presumably unimportant history. Also the reflog can get it back for you.
      Lose code? Only if conflict resolution is handled poorly, I think.

  • Comments are closed.