5 Git Commands That Don’t Get Enough Hype

As data scientists and developers, we have to deal with version control at one point or another. We might not fully understand all Git commands or fully memorize them, but we need to know how to use them to produce high-quality code. When programmers talk about Git, more often than not we’re thinking of specific Git commands: clone, push, pull, and commit.

Yes, these Git commands are popular because they deal with the most common concerns needed when dealing with Git. But what about the rest?

Git has different command categories — 13 to be precise — and each one deals with a specific aspect of version control. For example, init and clone are under the “create a project” category, while push and pull are in the “updating the project” category, and commit is used for basic snapshotting.

Let’s look at 5 Git commands that don’t get the hype they deserve — commands for inspecting, debugging and performing administrative tasks.

More From Sara A. MetwalliHow to Write Good Pseudocode

5 Important Git Commands

1. git diff

Do you want to check different commits or analyze the difference between commits and a working tree? Then git diff is the command for you! (If you’re not familiar with the concept, the working tree is the directory associated with your repository on your system.) To analyze the status of a repo, we often use git diff command in addition to git status and git log.

In general, we use git diff to get the difference between two things. These two things can be one of six scenarios. git diff can:

• show changes within a local repo, which we’ll see if any changes occur within the repo’s file directory.
• demonstrate the difference between local and remote repos. So, if you made changes on your local device and some on the git repo, git diff can help you identify exactly what changed.
• identify differences between two commits of the repo.
• show the difference between two specific files in two or more commits by showing the changes’ line numbers.
• show the difference between two local or remote branches.
• demonstrate the difference between two tags of the repo. Tags are often used to refer to working versions of the repo. For example, you can use git diff to identify the differences between version 1.0.0 and version 1.1.0 of your application.

2. git filter-branch

We use this command to rewrite our repo’s history by applying custom filters to each revision of the repo. The custom filters can change the working tree or the commits’ information, but it can’t change the commit times or merge information.

The general syntax for this command is git filter-branch branch_name. There are seven options for filters in this command so you can rewrite history for different aspects of the branch.

• subdirectory-filter: This filter only checks out a specific subdirectory of the branch.

• env-filter: We often use this filter to rewrite the environment information of a specific commit. For example, rewrite the author’s name, email or time of the commit.

• tree-filter: This filter option is very powerful; you can use it to check out all commits to the branch. This means it can change, remove, add, or even move files.

• index-filter: Similar to the tree-filter, but it doesn’t check out the entire tree, only the indices of it. This means it’s much faster, especially for large repos.

• parent-filter: This option changes a commit’s parents’ list.

• msg-filter: If you only want to change the commit messages, this filter is the way to go.

• tag-name-filter: If you want to edit the tags of your commits, use this command.

3. git bisect

This is probably one of the most important Git commands. Bugs can kill your application and sometimes debugging a repo is not an easy task so use git bisect to find bugs in a repo.

The entire idea behind git bisect is to perform a binary search in the commits history to find a particular regression bug — a problem resulting from an unrelated change in the code.

git bisect walks you through all recent commits, asking you if they are good or bad — depending on whether or not the regression bug is present in the commit. Doing this narrows down the options when you’re looking for the broken commit.

4. git grep

Trying to find something in your repo? Want to search all your branches for a specific file? git grep is here to help you do this with ease. We use git grep to search for a pattern in a working tree.

You can use git grep to search for either exact words or regex in the repo. There are various options you can use with this command. Assume we are looking for the doc in the repo; we can use one of these options:

• Search by line number git grep -n doc.

• Search only file names git grep -l doc.

• Search using a regex pattern git grep "f[^\s]\w".

• Specify how many matches in files git grep -c doc.

We can also use git grep to search for multiple words and/or relations. Moreover, git grep can search in a specific commit, branch, or even find all the occurrences between two commits or tags in the repo.

Before You Go...5 Ways to Write More Pythonic Code

5. git blame

We use the git blame command to display the authorial information for each commit. It helps us track bugs and find which commits produced the error. On a higher level, git blame inspects specific points in repo history, obtains information on who last committed, and what they really changed.

git blame displays the last author that modified a line; you can even specify exact line numbers, get the commits that affected that line, and learn who performed them.

Some people get confused between git blame and git log. Although they may sound similar, if you just need to display the commits performed, what they changed, and when they were done, it’s troublesome to use get blame to achieve that. In this case, git log is the better option. However, if you only want to display the metadata of the person who performed the commit, then git blame should be your command of choice.

Dealing with Git and version control is a lifelong learning experience. The more you use it, the more you learn and the more proficient you’ll become.

When getting started with Git, the standard commands always take the lead, overshadowing important commands that can make your life a lot easier. Commands such as grep, blame, and bisect can help you debug your commits, while diff and filter-branch will help you organize and inspect your repository.

Becoming fluent in these commands will help make your work faster, more efficient and (most importantly) more accurate.