Git - Alias

Previously, we learned how to work with GitHub, where the method of work was suitable for the work environment of nearly any company. It doesn’t matter if the company is working with Stash by Atlassian, or on a private GitHub repository, or on any other system.

One of the most important things is making sure there aren’t any conflicts between your version and that of the repository when you run a pull request. To do this there are a few things you need to do. I demonstrated in the previous article that we need to run pull from remote which is not necessarily the origin, but rather has another name. So our sequence of commands and actions should be:

Update the local repository:

git pull origin BRANCHNAME

Get an update from the remote repository:

git pull upstream BRANCHNAME

Create a new branch:

git checokout -b MYBRANCHNAME

Write code and run commit:

git add .
git commit -m'Commit Message'

Check for conflicts between the local version and that of the remote server:

git pull upstream BRANCHNAME
#OR
git rebase upstream BRANCHNAME

Push the changes to my branch, then go to the GitHub interface to run the pull request:

git push origin BRANCHNAME

This sequence of commands can be a bit grueling and confusing, especially for beginners, but also for the more experienced if their memory is not the best. Sometimes there are all kinds of flags that change the command such as git bramch -b (the -b creates a new branch). There are other flags that we still haven’t talked about in this series such as -prune. Sometimes we don’t want to create a commit message because we’re working with our own branches that we will upload to a specific branch in our repository, and only from that branch will we run a pull request. So anyway, no one can see them and the documentation about the changes that were made appears only in the pull request.

How easy it would be for example, if instead of writing git checkout -b BRANCHNAME every time we want to create a new branch, we could just write git cob BRANCHNAME. And how easy to simply write git save instead of git add, and then git commit -m’SAVE POINT’  each time that we need to run commit to our branch (not to the MASTER or a branch the someone else ever uses—just to our own branch).

Well, just for this we have git alias which allows us to create shortcuts for as many commands as we want. It’s really easy, and convenient too.

So how do we use it? For this, we’ll need to first find gitconfig. If you’re using Linux or Mac, it will be in:

~/.gitconfig 

The tilde ~ is the home directory of the user.

If you’re on Windows, it will be in:

C:\Users\MyLogin

There you’ll find a file call gitconfig. If it’s not there, just create it.

This file is really nice and easy to work with. You’ll find the username and email, the same that we configured at the very very beginning, remember?

[user]
       name = Ran Bar-Zik
       email = ran@bar-zik.com

If we add the alias, we can use them easily. Here’s an example:

[user]
       name = Ran Bar-Zik
       email = ran@bar-zik.com
[alias]
       co = checkout
       cob = checkout -b

If I save the gitconfig file, then from now on when I type git cob NEWBRANCHNAME, it will create a new branch as if I wrote git checkout -b NEWBRANCHNAME. Cool, eh?

And you can combine more than one command. For example:

[user]
       name = Ran Bar-Zik
       email = ran@bar-zik.com
[alias]
       co = checkout
       cob = checkout -b
       cm = !git add -A && git commit -m

If I write git cm “My Commit Message, it will be exactly as if I ran git add to every file, and then ran git commit -m.

Here’s an article that has pretty much all of the useful aliases. I also have a list of useful aliases and you are more than welcome to add to it.

Our next article in the series will cover git stash. It’s gonna be pretty interesting, so check back soon :)

About the author: Ran Bar-Zik is an experienced web developer whose personal blog, Internet Israel, features articles and guides on Node.js, MongoDB, Git, SASS, jQuery, HTML 5, MySQL, and more. Translation of the original article by Aaron Raizen.