8 tips to work more effectively with Git

Hi, it seemed to me a good idea to start translating more than just the release posts from the GitLab blog . To warm up, I took this post almost at random, so do not judge strictly. I would be glad if you help determine the choice of article for translation by selecting one of the options in the questionnaire

Git is a version control system with a huge amount of features. Trying to learn them all is quite tiring, so most users are limited to using only the basic set of commands. This article presents several tips for working with Git that you may not have known about. These tips will help you optimize your development process.

Aliases

One of the best ways to simplify working with Git is to use aliases for frequently used commands. This will help save time when typing commands in the terminal.

For example, aliases for the checkout , commit and branch commands can be created as follows:

 git config --global alias.co checkout git config --global alias.ci commit git config --global alias.br branch 

Now, instead of git checkout master just enter git co master .

You can also modify and add aliases directly by editing the ~/.gitconfig :

 [alias] co = checkout ci = commit br = branch 

Hiding (stashing) changes until commit

Imagine that in the process of working on a new feature there was an urgent need to make changes to the project. Committing incomplete functionality is not the best solution, but I don’t want to lose all my work on it.

Using the git stash command, you can temporarily undo the changes you have made without permanently deleting them:

 $ git stash 

This command temporarily hides the changes and leaves a clean working copy. Now you can switch to another branch to make urgent changes without making changes already made as commits.

To return the hidden functionality, just enter:

 $ git stash pop 

If hidden functionality is no longer needed, you can remove it with:

 $ git stash drop 

Command Line Comparison

A quick and easy way to compare changes between commits or versions of the same file is to use the git diff .

To compare the states of the same file between commits, enter:

 $ git diff $start_commit..$end_commit -- path/to/file 

To compare the changes between two commits:

 $ git diff $start_commit..$end_commit 

These commands will display the result in text form directly in the terminal window. For a more visual result, you can use git difftool . This command runs a special program to compare changes. One such program is Meld.

To configure Meld, enter:

 $ git config --global diff.tool git-meld 

Now you can use it:

 $ git difftool $start_commit..$end_commit -- path/to/file #  $ git difftool $start_commit..$end_commit 

Roll back changes

Sometimes when working on the code, it becomes clear that the changes made were unnecessary / incorrect and should be rolled back. Instead of doing undo for each change, it’s enough to reset the files on the HEAD commit branch:

 $ git reset --hard HEAD 

Or, for one specific file:

 $ git checkout HEAD -- path/to/file 

Further, if unnecessary changes have already been committed, for their rollback you need to enter:

 $ git reset --soft HEAD~1 

Better use of git blame

Git blame is used to find out who made changes to a specific line in a file. There is a set of flags that can be passed to this command, depending on what you want to display:

 $ git blame -w #    $ git blame -M #    $ git blame -C #       

In addition to the above tips for working with teams, there are a few general tips for working with Git.

Do a pull often

If you are using GitLab Workflow , then you are working in branches for featured functionality. While you are working on features in a separate branch, many changes can occur in the master branch, some of which may conflict with the added features.

In order to avoid such conflicts, you need to pull changes from the master branch into yours as often as possible. This will allow resolving possible conflicts as they appear and will make the subsequent merge of your branch much easier.

Frequent commits, rare pushes

Frequent commits logically share the added functionality and allow you to roll back individual parts of it if necessary. However, there is no need to push each commit to the server: the only thing it will lead to is clogging of the change history. Push only when your feature is ready.

Push only after testing changes

A good sign that the changes are ready to push, is the successful passing of tests. It also usually means that the block of implemented functionality is completed, and you can switch your efforts to the next one. Make changes only after passing all the tests, and then re-passing them on the side of the CI server.