4 Useful Git Commands That Will Make Your Life Easier

In the modern software development world, projects become bigger and it can be hard to manage and control the changes by multiple developers. It’s also difficult to find ways to simplify the process and make it more effective. That’s why using a version control system like Git is a must.

With the help of Git, you can monitor and control changes in particular project files, distribute and coordinate the workflow between multiple software developers. It also allows you to avoid a large amount of routine work and to get a comprehensive answer to the questions: Who did what and when?

In this article, we have prepared a list of 4 useful Git commands that help you save your time and simplify your working process.

1. git clean

Once in a while, every developer finds himself in such a situation when a particular untracked file becomes incorrect or outdated. One of the common reasons for this may be the waste removal that was generated during a merge or using external utilities.

If you previously deleted the files manually, searched for them and spent more time than required, then we have good news for you. Git provides an efficient tool for removing untracked files that are not in the staging area (an out basket for your project files): $ git clean.

Let’s define how it works with this example:

Step 1. Imagine that you start working on a particular functionality part, so first, you need to create a directory to store all the project files there. For example, you create a new folder called cats and add a picture into this folder.

    ➜
    ~
    mkdir cats
  

    ➜
    ~
    cp ~/Downloads/birman.jpg ./cats
  

Step 2. After a while, you develop a feature and realize that you need to remove particular modules. The reasons for this may be cancelling the task or understanding that you are doing something wrong. In order to delete these modules, initially, you need to check your working directory (folder) for changes using $ git status command.

    ➜
    ~
    git status -s
  

?? cats/

Step 3. Now you can see what project folder and files were changed, added, or deleted. Finally, you can remove all the files created during the current functionality development using the following command:

    ➜
    ~
    git clean -fdx
  

Removing cats/

To understand the command flags and additional opportunities like -fdx, let’s take a closer look at each option:

• -d

This flag option deletes untracked directories (folders) together with untracked files.

• -f

This flag option is the actual removal of untracked files. It will not remove untracked directories or files specified by .gitignore file.

    ➜
    ~
    git clean -f
  

Removing cats/

• -n

This flag option enables a “dry run” mode. It simply shows what files will be deleted without actually removing them. It is a superlative practice to always run git clean -n command first.

    ➜
    ~
    git clean -n
  

Would remove cats/

• -x

This flag option removes the files ignored by Git (mentioned in .gitignore file)

To conclude, most commonly you will use $ git clean -ndx and $ git clean -fdx commands. The procedure is simple: initially, you check what files are going to be removed, then you actually remove them (it is a non-reversible process).

Interested in learning more about software development in 2020?

Subscribe to our blog.

Name

E-mail

Subscribe

2. git pull --rebase --autostash

You may often work on a particular project functionality in cooperation with another engineer. In such a situation you often want to pull in the changes your colleague pushed to the remote repository and rebase your commits on top to form a proper update structure. The good news is that you can do it with: $ git pull --rebase.

Let’s define how it works through the following example:

Step 1. Imagine you start developing a new feature with another engineer and you both commit particular changes. Initially, you might want to pull in changes that were committed by your colleague. Here comes $ git log command which shows the full local commits history:

    ➜
    ~
    git log --oneline
  

fe7aa0 (HEAD -> master, origin/master) birman 
0a074ca hello, world 
cd2639b Initial commit

Step 2. Now you begin the development by creating a new file (i.e. a-lot-of-changes.txt), adding it to the staging area and committing all the changes.

    ➜
    ~
    touch a-lot-of-changes.txt
  

    ➜
    ~
    git add a-lot-of-changes.txt
  

    ➜
    ~
    git commit -m "A lot of changes"
  

Step 3. Then you might want to create a new file (i.e. one-more-change.txt) without adding it to the staging area for any reason. You then log the history of commits and see that the first staged file is stashed to the top of the structure.

    ➜
    ~
    touch "one-more-change.txt"
  

    ➜
    ~
    git log --oneline
  

c23f82a (HEAD -> master, origin/master) A lot of changes 
ffe7aa0 birman 
0a074ca hello, world 
cd2639b Initial commit

Step 4. In case there are uncommitted changes, you need to stash those changes first, then pull remote updates, and pop your stash to continue your work. This sounds difficult, but Git provides you with an additional option --autostash to automatically stash and pop your uncommitted changes.

    ➜
    ~
    git pull origin master --rebase --autostash -v
  

From gitlab.com:codica/git-commands-codica 
* branch master -> FETCH_HEAD 
= [up to date] master -> origin/master 
Changes from ffe7aa029e348b6b7e5fada33c01f74d0007a521 to 
e87684ea0ef5059cbb0234d666a840866475c843: 
README.md | 2 +- 
1 file changed, 1 insertion(+), 1 deletion(-) 
First, rewinding head to replay your work on top of it... 
Applying: A lot of changes

Step 5. Now we can check the result of the command execution via $ git log. We will make sure that the commit (e87684e (origin/master) fixed typo) of our colleague was positioned properly: after our shared starting point (ffe7aa0 birman) and before our last commit (434dc92 (HEAD -> master) A lot of changes).

    ➜
    ~
    git log --oneline
  

434dc92 (HEAD -> master) A lot of changes 
e87684e (origin/master) fixed typo 
ffe7aa0 birman 
0a074ca hello, world 
cd2639b Initial commit

Step 6. Now we can check that our file one-more-change.txt, that was not added to the staging area, did not disappear and automatically went in and out of the stash.

    ➜
    ~
    git status
  

?? one-more-change.txt

In brief, we have discussed $ git pull --rebase --autostash command in practice using the mentioned above examples. Thus, this command is a powerful tool to cooperate with multiple engineers while coding and be sure about keeping the branch up to date.

3. git branch --merged

Every developer has faced a situation when there are lots of branches already merged into master that are completely out of use. In this context, it is pretty time-consuming to remove all the branches manually one by one.

The good news is that an excellent stack of commands was created to save your time. This lifesaver solution allows you to manage and remove merged branches automatically in just seconds.

Let’s have a closer look at our example to understand what we mean:

Step 1. Imagine that you have worked for a while on a particular project, and you know that lots of branches were already merged into the branch master. You might want to remove those branches, but if the project is large, you are most likely to have a full list of merged branches:

    ➜
    ~
    git branch --merged
  

feature/one 
feature/three 
feature/two 
* master

Step 2. When you receive a full list of merged branches, you will most likely want to leave some important ones without removing. For this purpose, we can append the following number of arguments to pass important branches that we don't want to remove (like dev or master):

    ➜
    ~
    git branch --merged | egrep -v "(^*|master|dev)"
  

Thus, in order to indicate a branch that you don’t want to delete - just pass its branch_name to an egrep command like in the following example (branch_name won’t be removed):

    ➜
    ~
    git branch --merged | egrep -v "(^*|master|dev|branch_name)"
  

Step 3. Finally, to remove all local branches merged into the current branch without excluded ones, use the following command:

    ➜
    ~
    git branch --merged | egrep -v "(^*|master|dev)" | xargs git branch -d
  

Deleted branch feature/one (was 949df0d) 
Deleted branch feature/three (was 450980a) 
Deleted branch feature/two (was 1ac4223)

To sum up, let’s describe each command block functionality for clear understanding:

• $ git branch --merged. It provides you with a list of merged branches.
• $ git egrep -v "(^\*|master|dev)". Here you indicate what branches should not be removed.
• $ git xargs git branch -d. All the branches that remain after the egrep command are passed as an argument one by one to $ git branch -d (--delete) to be removed.

4. git reflog

Have you ever faced the situation when some commits are lost? This problem can be occurred due to experimenting with different Git commands and not understanding properly what they do. In such a manner, you may have the whole work vanished and even $ git log will show you nothing. So, how can we get out of this problem?

Fortunately, Git provides a solution to almost any trouble you may get in. In this context, your lifesaver is $ git reflog command. It is a useful tool which allows you to list all the commands that were executed on the head of the branches.

Moreover, you can choose any commit logged via $ git reflog and get back to particular changes. Everything you need is to choose the commit you want to rejoin and run $ git reset command.

To gain a complete understanding of all said above, let’s take a look at an following.

Step 1. Imagine that something went wrong and all the earlier created commits became unavailable. To check the commit history, you need to use $ git log command:

    ➜
    ~
    git log --oneline
  

cd2639b (HEAD -> master) Initial commit

Step 2. The terminal’s fatal output proves this fact. Initially, you need to get the list of the commands’ history by using the following command. Thus, we see that all our commits, except Initial commit, disappeared.

Of course, we can pull in the changes from a remote repository, but we didn’t push our feature and all the changes were lost. Fortunately, here comes $ git reflog for help:

    ➜
    ~
    git reflog
  

d2639b (HEAD -> master) HEAD@{0}: reset: moving to HEAD~9 
e8e8b2f HEAD@{1}: commit: [Feature] big feature 
b7b2808 (origin/master) HEAD@{2}: pull origin master: Fast-forward 
...

Step 3. Here we can see that someone has removed our commits (cd2639b (HEAD -> master) HEAD@{0}: reset: moving to HEAD~9) or used Git commands wrongly. The good news is that we can use $ git reflog to get back to the state before $ git reset was executed.

All we need is to refer to the following commit index and use $ git reset command:

    ➜
    ~
    git reset e8e8b2f --hard
  

HEAD is now at e8e8b2f [Feature] big feature

You might wonder what --hard flag does? This option resets the index and working directory of a commit.

Step 4. Let’s log the commits’ history to make sure that all the commits were recovered:

    ➜
    ~
    git log --oneline
  

e8e8b2f (HEAD -> master) [Feature] big feature 
b7b2808 (origin/master) Merge branch "feature/three" into "master" 
450980a (origin/feature/three) [Feature] Three 
0a41dda Merge branch "feature/two" into "master" 
1ac4223 (origin/feature/two) [Feature] Two 
556c8fa Merge branch "feature/one" into "master" 
949df0d (origin/feature/one) [Feature] One 
b1d801d one more change 
434dc92 A lot of changes 
e87684e fixed typo 
ffe7aa0 birman 
0a074ca hello, world 
cd2639b Initial commit

Here you can see that all the commits have been recovered and now we can refer to any version.

To sum up

For web developers, Git is a must-have magic wand and a lifesaver in managing application versions. There are tens of commands that may come in handy for different tasks.

In this article, we have discussed 4 advanced Git commands that will spare your time and automate your working process. Here is a recap of these commands’ functionality:

• $ git clean. Effective removal of the untracked files that are non-staged.
• $ git pull --rebase --autostash. An efficient stash and pop of uncommitted changes.
• $ git branch --merged | egrep -v "" | xargs git branch. Viable deletion of already merged branches excluding important ones.
• $ git reflog. An effective return to the point before something was broken (the log is removed after 90 days by default).

We highly recommend you to learn all the useful tools from many sides and different perspectives. Taken all together, this knowledge will give you an opportunity to save much time and become a more professional and productive software developer.