Git is a powerful tool but can be challenging to learn and remember commands for frequent use.
This is where Git alias comes in handy, Git aliases are user-defined shorthand for a sequence of commands that can be easily executed by typing a short name, which gets translated into the full command.
They are of 2 types.
- Git aliases and
- Shell Aliases
Creating Git Aliases
open ~/.gitconfig in your favorite editor- for my case VSCode.
code ~/.gitconfig
Then add your alias.
Before creating your alias, it is important to ensure that it does not conflict with any existing git commands, as this can cause issues.
[alias]
s = status -s
Now you can just type git s to view your git status.
My Aliases
Here are some of Aliases that use.
s = status
cnv = commit --no-verify
cane = commit --amend --no-edit
aa = add .
p = push
pf = push --force
la = log --oneline --decorate --graph --all
l = log --oneline --decorate --graph
rl= ref log
la = "!git config -l | grep alias | cut -c 7-"
But these are just a few which are useful for me, if you need to explore more Must Have Git Aliases
On
Shell Aliases
Unlike Git Aliases, Shell alias are stored in ~/.bashrc or ~/.zshrc
Creating Shell aliases.
open ~/.zshrc or ~/.bashrc in your editor.
Then add your alias in this format.
alias gs='git status -s'
So, when you are going to check, just write gs without the Git prefix.
One thing to take into account though before creating your alias is to make sure that your alias doesn't collide with the already existing git command which can mess
Hope Aliases makes your development more productive and faster.
If you find the content useful, you can follow me on Github or Twitter
References.
https://gist.github.com/mwhite/6887990
https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
Top comments (2)
Hey there! I just read your post on git aliases and I found it quite enjoyable.
What I would like to see would be a mention on the potential issues that may arise when creating Git aliases.
First of all, custom Git aliases can potentially conflict with already existing commands or aliases. If you choose a shorthand that is already used, the behaviour of Git will become unexpected. So it's a good idea to choose uncommon and unusual abbreviations, not frequently used by other applications. This leads to the second point.
Git aliases can potentially be difficult to remember. Although command shortcuts can speed up typing, it is possible to forget the abbreviated form of the command which can lead to not using this command after all. To avoid this you should use shorthands that are easy to remember and intuitive. Which again can lead to potential conflicts.
A third factor that must be taken into account is portability. Git aliases cannot be used outside of the local configuration file of the Git installation, which makes it difficult to utilize them across many computers or Git installations. It could be necessary to create new aliases on each instance when a user works across various computers or interacts with different Git installations.
The final point to consider when using Git aliases is the lack of transparency. Since you can create an alias that executes multiple commands sequentially, it's not always clear what is being executed behind the scenes. This can make it harder to troubleshoot errors or understand what's happening on your repository.
Hi @kalkwst ,
I agree with the potential issues of creating Git aliases and appreciate the points raised. It's important to be mindful of conflicts, rememberability, portability, and transparency.
To address the portability issue, users can consider using Shell aliases, which are easily shareable across different Git installations, especially if using a zsh config manager like oh my zsh.