In Git, how do you define an alias, and what changes when it starts with an exclamation mark?

## Defining one An alias is nothing more than a configuration key in the `alias` section, so every rule about scopes applies: `git config --global alias.co checkout` writes to `~/.gitconfig` and is available everywhere, while the same command without `--global` writes to one repository's `.git/config`. You can also edit the file directly, which is easier for long values: `[alias]` then `lg = log --oneline --graph --decorate --all`. `git config --get-regexp '^alias\.'` lists what you currently have, which is useful when moving to a new machine. ## Plain aliases Without a leading `!`, the alias value is expanded as arguments to `git`. `git lg` becomes `git log --oneline --graph --decorate --all`. Extra arguments you type are appended after the expansion, so `git lg -5` works naturally and `git co -b topic` works for `alias.co = checkout`. This is textual expansion, not a macro language: there are no parameters, no conditionals, and no way to inject an argument anywhere except at the end. ## Shell aliases Prefix the value with `!` and everything after it is passed to the shell. That unlocks pipelines, other tools, and multiple commands: `alias.cleanup = !git branch --merged | grep -v '\*' | xargs -r git branch -d`. Two behaviours are specific to shell aliases and both bite people: **Working directory.** A `!` alias runs from the top level of the working tree, not from where you typed it. If your alias operates on relative paths, they resolve against the repository root. Git sets the `GIT_PREFIX` environment variable to the path from the top level to your original directory, so an alias that must respect where you stood can use it. **Argument position.** Arguments are still appended at the end of the expanded string. `!echo Building && make` with a typed argument produces `... make <arg>`, not what you probably meant. The idiomatic workaround is to define and immediately call a shell function, which gives you real positional parameters: `!f() { git log --author="$1" --oneline "${@:2}"; }; f`. Everything you type lands as arguments to `f`. Inside a `!` alias, `git` means whatever `git` your shell resolves; some people write the full expansion carefully to avoid recursion surprises. ## Aliases cannot override built-ins Git only consults aliases for a command name it does not already know. Defining `alias.status = log` leaves `git status` doing exactly what it always did — the alias is simply never reached. This is deliberate: it means scripts and documentation that call standard commands keep working no matter what a user has configured. If you want a different default behaviour for a built-in, you change its configuration or write a differently-named alias; you cannot rename the command out from under Git. ## Where aliases should live Because `.git/config` is not tracked and never travels with a clone, repository-local aliases only exist for the person who created them. Aliases are personal ergonomics: keep them global, or in a dotfiles repository you install on each machine. A project that wants everyone to have the same helper is better served by a checked-in script than by an alias nobody else will have. ## Practical cautions A `!` alias runs arbitrary commands, so treat configuration from an untrusted source the way you would treat a downloaded shell script — this is one of the reasons Git never reads configuration from inside a cloned repository's tracked files. Keep destructive aliases explicit rather than short: an alias that force-pushes or hard-resets should be named so you cannot fire it by muscle memory. And prefer aliases that are transparent enough that you can still explain what the underlying command was in an interview, rather than ones that hide the mechanism you are expected to know.