.gitconfig Generator

Generate a .gitconfig file with user settings, core preferences, aliases, and tool configuration. Copy to your home directory.

Presets:

Configured Editor

vim

Default Branch

main

Config Sections

13 sections

File Size

55 lines (769 B)

Full Name

Email Address

Default Editor

Default Branch

Include git aliases (8 aliases)Include color settingsSet pull.rebase = true

.gitconfig

[user]
	name = Your Name
	email = you@example.com

[core]
	editor = vim
	autocrlf = input
	whitespace = trailing-space,space-before-tab

[init]
	defaultBranch = main

[pull]
	rebase = false

[push]
	autoSetupRemote = true

[fetch]
	prune = true

[color]
	ui = auto

[color "branch"]
	current = yellow bold
	local = green bold
	remote = cyan bold

[color "diff"]
	old = red bold
	new = green bold
	meta = yellow bold

[color "status"]
	added = green bold
	changed = yellow bold
	untracked = red bold

[alias]
	st = status
	co = checkout
	br = branch
	lg = log --oneline --graph --decorate --all
	unstage = reset HEAD --
	last = log -1 HEAD
	undo = reset --soft HEAD~1
	aliases = config --get-regexp alias

[diff]
	tool = default-difftool

[merge]
	conflictstyle = diff3

About the .gitconfig Generator

The ~/.gitconfig file is read by Git for every operation on your machine. This generator creates a well-structured config with user identity, core settings, and optional aliases likelg (pretty log graph),st (status), and undo (soft reset). Save the output to ~/.gitconfig on Linux/macOS or %USERPROFILE%\.gitconfig on Windows.

Built and maintained by Meet Shah · Last updated 18 July 2026

What this tool is used for

Setting up a new machine with the identity, editor and alias settings you always use.
Producing a config to compare against your current one after inheriting a machine.
Getting the syntax right for a conditional include that switches identity per directory.
Generating a starting file before adding work-specific settings by hand.
Checking which options a tool you just installed expects to be set.

Frequently Asked Questions

Where do git config settings live?: Three levels: system-wide, global in `~/.gitconfig`, and per-repository in `.git/config`, with the most specific winning. `git config --list --show-origin` is what tells you which file a surprising setting actually came from.
What should core.autocrlf be set to?: `true` on Windows and `input` on macOS and Linux — so the repository stores LF and the working tree gets platform-native endings. A `.gitattributes` file is better still, because it travels with the repo rather than depending on each contributor's setup.
Why configure pull.rebase?: Because the default merge creates a merge commit for every pull, cluttering history with commits that record nothing. `pull.rebase = true` replays your local work on top instead, which keeps a linear history — at the cost of rewriting commits you have not pushed.
What are the most useful aliases?: Short forms for the commands you type dozens of times — `st` for status, `co` for checkout, and a formatted `lg` for the graph log. The gain is not typing speed; it is that a well-formatted log becomes something you actually look at.
Should commits be signed?: Where authorship matters, yes. `commit.gpgsign = true` with a GPG or SSH key produces the verified badge and proves the commit came from you — which matters because the author field is plain text that anyone can set to anything.

Common errors and gotchas

Setting a global identity and then committing to a work repository with a personal address.
Assuming global config overrides repository config. Local settings win, which is usually what you want and occasionally surprising.
Setting the wrong line-ending behaviour for the platform, which shows every file as modified.
Putting the file in the wrong location, where Git never reads it and the settings appear not to apply.
Creating an alias that shadows a real Git command, which then behaves unexpectedly for everyone sharing the config.