.gitconfig Generator

Generate a complete ~/.gitconfig file ready to drop onto any machine. Fill in your name, email, preferred editor and a few behavioural options — pull mode, line endings, prune — and the generator emits a clean INI-format config with well-commented sections. The optional aliases block adds a curated set of shortcuts every Git user should have.

How to use the .gitconfig Generator

Fill in your name and email — these appear in every commit you make and cannot be easily changed retroactively. Choose your editor: VS Code requires the --wait flag so Git blocks until you close the file; vim/nano/nvim are shell-blocking by default.

The default branch sets init.defaultBranch, which controls what Git names the first branch when you run git init. Set it to main to match GitHub/GitLab defaults. Pull mode determines what git pull does when there are divergent commits: merge creates a merge commit, rebase replays your commits on top (cleaner history), ff-only refuses to pull if a fast-forward is not possible (safest for shared branches).

Auto CRLF controls line-ending normalisation. Use input on macOS/Linux: it normalises to LF on commit but leaves files untouched on checkout. Use true on Windows to convert CRLF↔LF automatically. The aliases block adds short commands: git st, git lg (pretty log with graph), git last (show last commit), git unstage (reset HEAD). Copy or download the config, then run cp gitconfig ~/.gitconfig.

About ~/.gitconfig

Git reads configuration from three layers: the system config (/etc/gitconfig), the user config (~/.gitconfig or ~/.config/git/config), and the repository config (.git/config). Values in more-specific files override broader ones. The ~/.gitconfig file is the right place for personal identity, editor preferences, global aliases and default behaviour — anything that should apply to every repo on the machine.

The file uses INI format: section headers in square brackets ([user], [core]) followed by key = value pairs. Section names are case-insensitive. Git has evolved hundreds of config keys across versions; the ones generated here are the stable, widely-used subset that every developer benefits from.

A common mistake is setting a weak pull mode (pull.rebase = false) globally and then getting merge-commit noise in linear projects. Another is omitting fetch.prune, which lets stale remote-tracking branches (e.g. origin/feature/old-thing) accumulate indefinitely. Getting these right once in your global config saves friction on every future project.

Common use cases

  • Provisioning a new machine — generate a config once, keep it in a dotfiles repo, and apply it to every new laptop or cloud VM in seconds.
  • CI/CD environments — minimal gitconfigs for Docker images or CI runners that need a committer identity for automated commits.
  • Onboarding new developers — share a team-standard config that sets the correct pull mode and line-ending policy to prevent cross-platform issues.
  • Alias standardisation — ensure everyone on the team has the same git lg pretty-log command so documentation and screencasts are reproducible.
  • Switching editors — regenerate to update the core.editor setting when moving from vim to VS Code.

Frequently asked questions

Does this replace my existing .gitconfig?
The generated file is a complete replacement. If you have custom settings in your existing ~/.gitconfig (e.g. credential helpers, GPG signing), copy those sections into the output before applying. Use git config --list --show-origin to see all current settings and their sources.

What pull mode should I use?
For feature-branch workflows: rebase keeps a linear history. For trunk-based development with shared branches: ff-only prevents accidental merges. The merge default is safest for beginners because it never rewrites history, but produces noisy merge commits in long-lived feature branches.

Why does VS Code need --wait?
Without --wait, Git launches VS Code and immediately thinks the editor exited (because the code CLI returns instantly). Git then reads an empty or unchanged file and aborts. The --wait flag blocks the CLI until all VS Code windows for the opened file are closed.

Can I have different identities per repository?
Yes. Run git config user.email "[email protected]" inside the repo, or use the [includeIf] directive in ~/.gitconfig to conditionally include a separate file based on the repo path: includeIf "gitdir:~/work/" path = ~/.gitconfig-work.

What is fetch.prune?
When set to true, git fetch automatically deletes local remote-tracking branches (e.g. origin/deleted-feature) that no longer exist on the remote. Without it, deleted branches accumulate and git branch -r output becomes cluttered.