Git has a strong commitment to backwards compatibility: many powerful features are hidden behind options rather than exposed as default behaviour. 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 :
[code]$ git config --global alias.please 'push --force-with-lease'[/code] 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
[code]$ git config --global alias.commend 'commit --amend --no-edit'[/code] 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.
[code]$ git add Dockerfile$ git commit -m ‘Update Bitbucket pipeline with new Docker image’# (facepalm)$ git add bitbucket-pipelines.yml$ git commend[/code] git it
[code]$ git config --global alias.it \'!git init && git commit -m “root” --allow-empty'[/code] 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 it both 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 !
[code]$ cd shiny-new-thing$ git itInitialized empty Git repository in /shiny-new-thing/.git/[master (root-commit) efc9119] root[/code] git staaash
[code]$ git config --global alias.stsh 'stash --keep-index'$ git config --global alias.staash 'stash --include-untracked'$ git config --global alias.staaash 'stash --all'[/code] 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:
[code]git stsh # stash only unstaged changes to tracked filesgit stash # stash any changes to tracked filesgit staash # stash untracked and tracked filesgit staaash # stash ignored, untracked, and tracked files[/code] If in doubt, the long one ( git staaash ) will always restore your worktree to what looks like a fresh clone of your repository.
[code]$ git config --global alias.shorty 'status --short --branch'[/code] 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:
[code]$ git statusOn branch masterChanges to be committed: (use “git reset HEAD …” to unstage)[/code] [code]modified: package.json[/code] [code]$ git config --global alias.commend 'commit --amend --no-edit'0[/code] [code]modified: package.json[/code] [code]$ git config --global alias.commend 'commit --amend --no-edit'2[/code] [code]$ git config --global alias.commend 'commit --amend --no-edit'3[/code] git shorty tells me the same thing in 3 lines:
[code]$ git config --global alias.commend 'commit --amend --no-edit'4[/code] (OK, so I actually have this aliased as git st for brevity, but I couldn’t resist.)
[code]$ git config --global alias.commend 'commit --amend --no-edit'5[/code] If you’re using a standard non-rebasing branching workflow, running a standard git merge to combine feature branches with 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.