Lesser Known Git Commands

Git has a strong commitment to backwards compatibility: many powerful features are hidden behind options rather than exposed as default behavior. Fortunately, Git also supports aliases, so you can create your own commands that do all manner of Git magic. Here’s a selection of the more useful (or at least entertaining) aliases defined in my .gitconfig:

Git Please

$ git config --global alias.please 'push --force-with-lease'

Every developer has had the chat with their team lead about force pushing to a shared branch (i.e. don’t do it). Rebasing, amending, and squashing. are all good fun right up until you rewrite some shared history and spill duplicate commits all over your repository. Fortunately, Git won’t let you rewrite history on the server willy-nilly. You have to explicitly pass the --force option to git push to show you mean business. But force pushing is a bit heavy-handed: It stomps the upstream branch with your local version, and any changes that you hadn’t already fetched are erased from history.

Quality meme courtesy of  @tarkasteve

Git’s --force-with-lease option is far more polite: it checks that your local copy of the ref that you’re overwriting is up-to-date before overwriting it. This indicates that you’ve at least fetched the changes you’re about to stomp. Since git push --force-with-lease is rather a lot to type out each time, I’ve created a polite alias for it: git please

Git Commend

$ git config --global alias.commend 'commit --amend --no-edit'

Ever commit and then immediately realize you’d forgotten to stage a file? Fret no more! git commend quietly tacks any staged files onto the last commit you created, re-using your existing commit message. So as long as you haven’t pushed yet, no-one will be the wiser.

$ git add Dockerfile
$ git commit -m ‘Update Bitbucket pipeline with new Docker image’
# (facepalm)
$ git add bitbucket-pipelines.yml
$ git commend

Git It

$ git config --global alias.it \
'!git init && git commit -m “root” --allow-empty'

The first commit of a repository can not be rebased like regular commits, so it’s good practice to create an empty commit as your repository root. git itboth initializes your repository and creates an empty root commit in one quick step. Next time you spin up a project, don’t just add it to version control: git it!

$ cd shiny-new-thing
$ git it
Initialized empty Git repository in /shiny-new-thing/.git/
[master (root-commit) efc9119] root

Git Staaash

$ git config --global alias.stsh 'stash --keep-index'
$ git config --global alias.staash 'stash --include-untracked'
$ git config --global alias.staaash 'stash --all'

git stash is one of the most delightful and useful Git commands. It takes any changes to tracked files in your work tree and stashes them away for later use, leaving you with a clean work tree to start hacking on something else. However if you’ve created any new files and haven’t yet staged them, git stash won’t touch them by default, leaving you with a dirty work tree. Similarly, the contents of untracked or ignored files are not stashed by default.

I’ve created a few handy aliases to handle different variations of git stash, based on which bits of your work tree you need to stash:

git stsh      # stash only unstaged changes to tracked files
git stash     # stash any changes to tracked files
git staash    # stash untracked and tracked files
git staaash   # stash ignored, untracked, and tracked files 

If in doubt, the long one (git staaash) will always restore your worktree to what looks like a fresh clone of your repository.

Git Shorty

$ git config --global alias.shorty 'status --short --branch'

I run git status probably more than any other Git command. Git’s inline help has gotten a lot more friendly over the years, which is excellent for beginners, but the output is overly verbose for those more familiar with Git. For example, git status emits 18 lines to tell me that I have a couple of staged, unstaged, and untracked changes:

$ git status
On branch master
Changes to be committed:
  (use “git reset HEAD <file>…” to unstage)
  
    modified: package.json
    
Changes not staged for commit:
  (use “git add <file>…” to update what will be committed)
  (use “git checkout -- <file>…” to discard changes)
  
    modified: package.json
    
Untracked files:
  (use “git add <file>…” to include in what will be committed)
  
    index.js

git shorty tells me the same thing in three lines:

$ git shorty
## master
AM test
?? .gitignore

(OK, so I actually have this aliased as git st for brevity, but I couldn’t resist.)

Git Merc

$ git config --global alias.merc 'merge --no-ff'

If you’re using a standard non-rebasing branching workflow, running a standard git merge to combine feature branches with the master is actually not ideal. With no options, git merge uses the --ff merge strategy, which will only create a merge commit if there are no new changes on the master branch, otherwise it simply “fast forwards” your master branch to point at the latest commit on your feature branch. Only sometimes creating a merge commit makes it tricky to reason about which code was developed on which branches when looking through your git history.

Git merc uses the --no-ff strategy, to always create a merge commit.

Incidentally, --no-ff is also what we use under the hood (by default) when merging pull requests in Bitbucket.

Git Grog

$ git config --global alias.grog 'log --graph --abbrev-commit --decorate --all --format=format:"%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(dim white) - %an%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n %C(white)%s%C(reset)"'

My git grog (or “graphical log”) alias has evolved over the years to the point where I’m no longer sure I understand exactly what it does. But it sure looks pretty:

Here’s the standard git log for comparison:

There are all sorts of pretty formats available, so fork the command above and make it your own!

For the GUI Fans

If you’re a Git GUI fan and using Mac or Windows, you might be using our free Git client: Atlassian SourceTree. If so, you can take advantage of these aliases by creating a new custom action — and optional keyboard shortcut — in your SourceTree preferences:

Then you can access it via the Actions -> Custom Actions menu, or your choice of keyboard shortcut:

Happy aliasing! If you have some neat Git aliases of your own, share them in the comments, or tweet me @kannonboy.