DEV Community

Cover image for Using Aliases to Speed Up Your Git Workflow
Robert Cooper
Robert Cooper

Posted on • Edited on

Using Aliases to Speed Up Your Git Workflow

Leveraging aliases when working with git can help make you more efficient with using the popular version control system. Listed below are some of my absolute favourite and most used aliases when working on a project that uses git.

It should be noted that when i'm talking about aliases, I mean bash/zsh aliases and not git aliases.

What's the difference? Bash/Zsh aliases are setup in a .bashrc or .zshrc file and allows you to assign a command to a shorthand version. For example, you could alias git log to be gl, which would save you a few characters of typing. Git aliases allow you to similarly assign a git command to a shorthand version, but you still have to type git prior to the shorthand. For example, you could alias the git log command to be l and then you would invoke the command by typing git l. All git aliases are set in a .gitconfig file which is usually found in a computer's HOME directory.


Adding and Amending Commits

gaa

git add -A
Enter fullscreen mode Exit fullscreen mode

Adds all changes to staging.

gcm

git commit -m
Enter fullscreen mode Exit fullscreen mode

Creates a new commit with all staged files and uses the given message as the commit's message.

Example:

gcm "This is my commit message describing the changes"
Enter fullscreen mode Exit fullscreen mode

gcma

git commit -a -m
Enter fullscreen mode Exit fullscreen mode

Adds all files to staging and makes a commit using the given message as the commit's message.

Example:

gcam "This is another commit message!"
Enter fullscreen mode Exit fullscreen mode

gca

git commit --amend --no-edit
Enter fullscreen mode Exit fullscreen mode

Moves the currently saved files into the previous commit message. The --no-edit flag is passed to git commit --amend to keep the previous commit message (this is usually the case).

If the previous commit message should be changed, I've aliased git commit --amend --no-edit to gcae. It does the same as gca, but it opens up the git editor to edit the previous commit's message. In my case, I've setup VS Code to be my default git editor since i'm not proficient with VIM.

Previous commit message displayed in VS Code with instructions on how to change the commit message.

gcaa

git add --all && git commit --amend --no-edit
Enter fullscreen mode Exit fullscreen mode

This command is useful to use if some changes that have been made should be a part of the previous commit. It will add all newly modified files to staging and then it will amend the previous commit with those changes.

gnope

git checkout .
Enter fullscreen mode Exit fullscreen mode

Removes all the changes detected by Git.

gwait

git reset HEAD
Enter fullscreen mode Exit fullscreen mode

Unstages everything.

gundo

git reset --soft HEAD^
Enter fullscreen mode Exit fullscreen mode

Undoes the last commit and moves the files in the commit to staging.

Reading history

gl

git log --graph --pretty='\''%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset'\'' --abbrev-commit
Enter fullscreen mode Exit fullscreen mode

Logs previous commits in a concise manner. The argument passed to --pretty is defining the information that should get displayed for each commit (i.e. commit hash, branch name, commit message, date of commit, and author). Definitely wouldn't want to type this out every time!

gco

git checkout
Enter fullscreen mode Exit fullscreen mode

Allows to switch between branches.

Example:

gco other-branch-name
Enter fullscreen mode Exit fullscreen mode

Pushing & Pulling To/From Remote

gps

git push
Enter fullscreen mode Exit fullscreen mode

Updates the remote.

gpsf

git push --force-with-lease
Enter fullscreen mode Exit fullscreen mode

Overrides the remote branch with the local branch if no one else has commited to the remote. It is considered to be a safer approach than using git push --force.

gpl

git pull --rebase
Enter fullscreen mode Exit fullscreen mode

Fetch updates from the remote and rebase the local branch with the upstream branch. This avoids any merge commits that may occur when using git pull.

Rebasing

grb

git rebase
Enter fullscreen mode Exit fullscreen mode

Rebases the current branch with another branch.

Example:

grb origin/master
Enter fullscreen mode Exit fullscreen mode

grn (shell command)

grn() { git rebase -i HEAD~"$1"; }
Enter fullscreen mode Exit fullscreen mode

This is actually a shell command which allows for variables to be passed in as arguments. The $1 is a placeholder for an argument that gets passed to the grn function. This function accepts N as an argument, where N is the number of commits to perform an interactive rebase on.

Example:

Example usage of the grn shell command

grbic (shell command)

grbic() { git rebase -i "$1" ; }
Enter fullscreen mode Exit fullscreen mode

Accepts a commit hash as an argument and performs an interactive rebase back to the passed commit hash.

Example:

Example usage of grbic shell command

grba

git rebase --abort
Enter fullscreen mode Exit fullscreen mode

Aborts an interactive rebase and restores the git state to the moment the git rebase command was run.

grbc

git rebase --continue
Enter fullscreen mode Exit fullscreen mode

Continues an interactive rebase after conflicts on a commit have been resolved.


Ok, I know that was a lot of aliases, so sorry for rambling on about them. I would encourage others to start aliases more often to speed up their development. Let me know if any of those were helpful or if you've got some favourite aliases you'd like to share.


If you found this article consider following me on Twitter, Github, or LinkedIn.

Top comments (35)

Collapse
 
ben profile image
Ben Halpern

This also acts as sort of a cheatsheet for things you might want to be doing in the first place, while giving a more compact command to do so.

Not everybody loves aliases, but this looks like a great guideline for those who do or want to start.

Collapse
 
robertcoopercode profile image
Robert Cooper

Not everybody loves aliases

This is true. I worked with a guy that refused to use aliases because he thought he would forget the underlying command behind the alias.

Collapse
 
jbristow profile image
Jon Bristow • Edited

It’s less that and more having your muscle memory be completely wrong as soon as you ssh somewhere.

Aliases are ok... but anyone with a bloated vimrc file can tell you how strange it feels to use the defaults. (Seriously, using vim-surround is basically the main reason I still use vim)

EDIT: and typing git commands are a very small part of my workflow, so it seems wasteful to alias them. And I will absolutely never add -A... I’m too paranoid about committing something I didn’t mean to.

Thread Thread
 
codeandclay profile image
Oliver

I don't have many aliases for git commands but seeing git add -A has inspired me to add one more to my small list:

alias gip='git add ${FILE} -p'

As in: git add file.rb -p. The -p flag tells git that you want to select which individual lines/hunks get committed. It's the scalpel to -A's mallet.

The alias allows me to do it this way: gip file.rb

Thread Thread
 
jbristow profile image
Jon Bristow

SInce i work in feature branches that get squash merged in a few days, I don’t really understand why you would be doing more than one thing at once...

Thread Thread
 
jessekphillips profile image
Jesse Phillips

I don't think squash merge should exist. The commit message sucks, many times your feature can be good individual changes (valuable outside the feature) it is pretty easy to finalize the order and squash with a rebase --interactive.

I'm said --fixup isn't listed as as alias.

Collapse
 
alainvanhout profile image
Alain Van Hout

My general opinion is very much 'use whatever works best for you'.

For me personally though, aliases like this are equivalent to improving the speed/performance of your car by speeding up how quickly you can get into and out of the car.

Collapse
 
aurelkurtula profile image
aurel kurtula

Haha, that's why I bookmarked it. Apart from add, commit -a -m, push --all and branching I do nothing else. And that I think is powerful, I only imagine how much power I'd get if I could be bothered learning the rest.

Collapse
 
kayis profile image
K

My favorites are:

alias whelp="git reset --hard"
alias weekend="git push --force"
Collapse
 
jsn1nj4 profile image
Elliot Derhay

Both funny examples. My favorite (when needed) is git rip-history (force-push).

Other than that, I only have a couple that are useful for my workflow.

One that I haven't seen elsewhere is this:
git email (git config --global user.email).

Also, I realized while typing this that yours were bash aliases like above. I still haven't made the transition from git aliases...

Collapse
 
vitalcog profile image
Chad Windham

Oh wow. You made WAY more than me. I did this a while back, my aliases are;

push (git push),
pull (git pull),
add (git add *),
commit (git commit -m),
check (git checkout),
branch (git branch)

That's about all I ever use/felt comfortable aliasing. I also didn't go to the same level of abbreviation as you. But I enjoyed your list, was fun to see how somebody else chose to implement the same idea.

Collapse
 
codevault profile image
Sergiu Mureşan

Thank you for an in-depth list of common git commands. If I weren't on Windows I might be using some of them. (gl especially)

Using aliases is fine for the most part. Just so that people don't jump directly into using them, here are some downsides to this:

  • You won't remember what each command does if you end up with too many too complex
  • They work only on your own machine... I wouldn't want to waste time googling git commands when helping one of my colleagues :/
  • If you use git extensively you might end up adding an alias for most parameters thus getting you lost in a sea of aliases

Overall, I think you should try it for the most used commands (like status, commit and pull), it definitely saves up some time.

Collapse
 
robertcoopercode profile image
Robert Cooper

You can use aliases on Windows? That surprises me.

Collapse
 
codevault profile image
Sergiu Mureşan

Apparently, you can.

I use git aliases and they are good enough for me... I just don't want to deal with batch... shivers

Collapse
 
mrtnrdl profile image
Martin Riedel

Interesting list of aliases you have - some are similar and some quite different than mine. I tried so stick with a two-character rule though.

you could try to use capitalisation to further shorten the necessary keystrokes a bit.
For example i use ga for git add <file> and gA for git add --all.

Collapse
 
robertcoopercode profile image
Robert Cooper

Nice, I like that

Collapse
 
kungtotte profile image
Thomas Landin

I rely on git aliases rather than shell aliases, and I try not to go overboard with the amount of aliases either.

I use YADM to manage my dotfiles and since it wraps git it will automatically pick up on git aliases, e.g yadm alias is the same as git alias, but I couldn't do yadm zsh-alias.

Shortening some commands is highly useful if I do them a lot, but if I write a bunch of aliases for nearly everything I've replaced learning git commands with learning git aliases. It's increasing my mental workload instead of easing it because I have to memorize the alias and what it stands for.

I also have to use other VCS sometimes, and by retaining the git prefix on git commands I find it's easier to remember what is what since terminology is similar but not identical between VCS.

Collapse
 
robertcoopercode profile image
Robert Cooper

I haven't heard of YADM before you mentioned it. I will look into it since I don't have a solution to manage all of my dotfiles yet.

Collapse
 
kungtotte profile image
Thomas Landin

There's a whole bunch of options in that space, but I prefer the simplicity and straightforwardness of YADM. It's basically just a wrapper around git allowing you to track files without making an actual repository, i.e. it only cares about files you manually add to it so a yadm status won't list dozens of unrelated files and folders.

It also imposes no restrictions on folder structure etc.

Collapse
 
drhyde profile image
David Cantrell • Edited

The one that I use a lot (I've got it as a shell script rather than as an alias or function) is ...

#!/bin/bash
SOURCE=$1
NUM=$2

if [ "$SOURCE" == "-h" -o "$SOURCE" == "" ]; then
    echo
    echo Usage: pick-many-cherries SOURCE COUNT
    echo
    echo Cherry-pick the last COUNT commits from SOURCE in chronological order.
    echo There is NO ERROR CHECKING.
    echo
    exit
fi

for i in {% raw %}`git log $SOURCE |grep ^commit |head -$NUM |awk '{print $2}' |tac`{% endraw %}; do git cherry-pick $i;done
Collapse
 
no_fear_inc profile image
Mario Peshev

Just stumbled upon this one -- great job!

I've been using similar aliases over the past few years. Here's what works for me (someone may relate and adapt accordingly):

  • gadd (git add)
  • gommit (git commit -m)
  • gista (git status)
  • gullom (git pull origin master)
  • gushom (git push origin master)
  • gullod (git pull origin develop)
  • gushod (git push origin develop)
  • gibra (git branch)
Collapse
 
jvanbruegge profile image
Jan van Brügge

I wouldnt use bash aliases for the commands, just for git itself. That way you keep tab completion on the aliases.
For example:
g l = g log --pretty=oneline --graph
g caa = g commit -a --amend
The g is a normal bash alias

Collapse
 
robertcoopercode profile image
Robert Cooper

Tab completion still works for me when I use zsh aliases.

Collapse
 
bgadrian profile image
Adrian B.G.

Definately you are not a lot or not at all productive with aliases, if the commands are small and used rarely, like the git is.
Plus the cognitive load is bigger, because u still have to learn the underline commands when u need more custom params, so is only a new layer of complexity in your head.

You can save 10s per day with alises and waste 1h for a debuging that could be avoided.

I use a limited amount of aliases but I removed my own and switched to a popular framework called github.com/Bash-it/bash-it