version control system

8 Tips to help you work better with Git



Git is a very powerful version control system. It can be a little bit daunting to try to learn everything around it, so most people just use the basic commands. We want to give you here some help with some tips you may or may not have heard. Either way, these tips can make your workflow a little easier.

Git aliases

One of the best ways to ease your daily workflow with Git is to create aliases for common commands you use every day. This can save you some time in the terminal.

You can use the following commands to create aliases for the most used Git commands, checkout, commit and branch.

This way, instead of typing git checkout master you only need to type git co master.

You could also edit them or add more by modifying the ~/.gitconfig file directly:


   co = checkout

   ci = commit

   br = branch

Stashing uncommitted changes

Let’s say we are working on a new feature, but there is an emergency and we need to fix to our project immediately. We don’t want to commit an unfinished feature, and we also don’t want to lose our current changes.

The solution is to temporarily remove these changes with the git stash command:

The git stash command hides these changes, giving us a clean working directory. We’re now able to switch to a new branch to make our important updates, without having to commit a meaningless snapshot just to save our current state.

Once you are done working on the fix and want to show your previous changes again, all you need to is run:

And your changes will be recovered. If you no longer need those changes and want to clear the stash stack you can do so with:

Compare commits from the command line

An easy and quick way to compare the differences between commits, or versions of the same file is to use the command line. For this you can use the git diff command.

If you want to compare the same file between different commits, you do the following:

And if you want to compare the changes between two commits:

These commands will open the diff view inside the terminal, but if you prefer to use a more visual tool to compare your diffs, you can use git difftool. A really great diff viewer/editor is Meld.

To configure Meld:

Now to start viewing the diffs:

# or

Resetting files

Sometimes when you start modifying your code, you realize that the changes you did are not that good and would like to reset your changes. Instead of clicking undo on everything you edited, you can reset your files to the HEAD of the branch:

Or if you want to reset a single file:

Now, if you already committed your changes, but still want to revert back, you can use:

Use Git blame more efficiently

Git blame is a great tool for finding out who changed a line in a file, but there are ways you can use it more efficiently. You can pass different flags, depending on what you want to show.

Now that you know some very useful tips about working with Git, let us give you some other tips on how to best use Git within your workflow.

Pull frequently

If you are using the GitLab Workflow, it means that you are working on feature branches. Depending on how long your feature takes to implement, a lot of changes might have been made to the master branch.

In order to avoid major conflicts at the end of the development of your feature, you should pull the changes from the master branch to your branch often. This will allow you to resolve any possible conflicts as soon as possible and it will make merging your branch to master easier.

Commit often, but don’t push every commit

Committing your changes often will keep your changes concise and make them easier to revert, if you were to need that. But it is not necessary to push every single commit to the server, as it will appear in the activity feed and probably spam your colleagues. Work on your changes until you are ready to push.

Push when changes are tested

A nice sign that your changes are ready to push is when they have been tested and the tests are green. This usually also means that this part of your feature is done and you can concentrate on the next part. Push your changes once this has been done and let the CI server test them again.

Do you think you can beat this Sweet post?

If so, you may have what it takes to become a Sweetcode contributor... Learn More.

Pato is a ruby lover, avid gamer, loves dogs and is currently a developer at Gitlab, Inc.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *