• We are trusted partners of:

Simple Git Command Line Tricks

Posted by | October 17, 2016 | Development | No Comments

There are fancier alternatives to all of the tasks below, but there are times when the direct CLI (command-line interface) approach works best or it’s the only option. It’s definitely faster than any git GUI (graphical user interface) frontend that I’ve ever tried and oftentimes even more user-friendly. So here are some of the most common uses of the git CLI.

 

Quickly searching the history

In order to make git show all the changes made in the current repo, issue this:

The “p” in the flag comes from “patch” and its primary function is to output a patch-usable version of the changes. You can ignore the file/directory name and you will get a list of all the changes ever made in the project, but unless the project is relatively small or you only want to look at a small recent change, you’ll probably want to be more specific. By default, the output is piped to the standard less utility, so it’s easy to search the changes by pressing /, typing the searched word and then pressing enter. Here is what happens when searching for shipmentValidation  in the history of a file:

git-log-search-1

(colors are enabled by setting the color.ui to true: git config color.ui true  – I recommend enabling this anyway)

In case the first occurrence is not the one you were looking for, you can navigate to the next one by pressing “n” (for “next”). Going back to the previous occurrence is Shift+n. Somewhere before of the occurrence you were looking for, you’ll find the details of the commit.

If the log outputs too much info, you can always add more filters, like the name of the author:

List the branches where a commit is present

Ever wondered if a commit is present in a certain branch? Here is how you find out:

git branch --contains f5d4e2

where f5d4e2  is the shortened commit hash. A sample output:

This means that commit 2b790a  is present in the develop  and master  branches, of which the starred branch, develop , is the current one.

Rebase a branch instead of merging

The easiest way to bring the changes from another branch into your current branch is to merge that branch into yours, which is the case for instance of the mainline branch. However, if your current branch has some commits that are not present in the mainline, then the merge will produce a merge commit on top of your commits. A somewhat cleaner and more elegant solution is to rebase your commits on top of the ones coming from the mainline. Assuming that your master branch is up-to-date with the remote and you are on another working branch, simply issue:

Here is a sample output:

The git output is pretty self-explanatory: the HEAD  of the branch is pushed back to match the latest master branch commit in the current branch, then the commits from the updated master are added on top of that HEAD  followed by the commits only found in the current branch. No merge commit as you can see. Alternatively, you can instruct the pull  operation to rebase instead of merge:

Or configure pull to always rebase instead of merging:

The overlooked git grep

This is one of the most basic git functions, yet one that people often overlook. It’s a great help when you need to search all the versioned files in your project really quick.

The command supports most flags that the standard grep utility supports, but will only search files that have been versioned, which in most cases is actually what you want. You can easily specify a particular subpath of the project to search:

Well, that’s all, guys. I hope you’ll find them useful! Good luck!

 

«Go back

About

Leave a Reply

Your email address will not be published.