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:
git log -p file_or_directory_name
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:
(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:
git log -p --author=Joe file_or_directory_name
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:
$ git branch --contains 2b790a * develop master
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:
git rebase master
Here is a sample output:
$ git rebase master First, rewinding head to replay your work on top of it... Applying: My commit from the current branch being rebased
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:
git pull --rebase origin master
Or configure pull to always rebase instead of merging:
git config pull.rebase true
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.
git grep string_to_search
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:
git grep string_to_search path/to/some/directory
Well, that’s all, guys. I hope you’ll find them useful! Good luck!
