Git CLI tips and tricks to be more productive

kpunith8 profile image Punith K ・5 min read

If you are a software developer you must be aware of the most popular version control system used git. I love git CLI for my day-to-day developer tasks, I use it for rebasing, committing and to resolve merge conflicts and so on. Few prefer GUI clients such as Sourcetree over CLI. Being a developer using a CLI makes you look smart in front of non-developers and you can type faster over time.

In this post, I'm going to explain to you the useful commands that I'm using for years and have benefited me to be more productive, hope this post will help you to be a little more productive than before.

Here goes the list,

Checkout to last checked out branch

Let us say you have created a fix-payment-bill-issue branch from the master branch to add a new feature or to fix a bug and want to switch to the last branch you were in, use the following command. This will be useful when you don't remember the branch name that you have checked out last time.

$ git checkout -

Check whether the current branch is merged with the targeted branch

This will be useful to know whether your changes were merged with the targeted branch.

  $ git branch --merged <targeted-branch>

Copy the files from another branch without switching the branch

Copy a file from another branch without switching branch, make sure the file is committed in another branch.

  $ git checkout <target-branch> -- <complete/path/to/file.js>

Search for a particular text in the commit message

Search git log with a particular text string, it lists all the commits matching the string

  $ git log -S'<search-string>'

Add the modified and uncommitted files to the previous commit

Add the modified and uncommitted files to the previous commit without changing the commit message, new files should be added to the staging.

  $ git commit -a --amend -C HEAD

Remove the branches that are deleted from remote in the local copy

Remove the local branches no longer on remote

   $ git remote prune origin

   $ git fetch -p

Skip the hooks from executing on commit

If you have configured hooks to check for linting or pre-checking for some required steps before committing the changes. But you want to commit your changes without these checks, since there are lots of issues in the initial code, to avoid the hooks from being blocked from committing the changes, do this instead and commit it, use --no-verify instead of -n if you prefer a more verbose way to explain what it is.

  $ git commit -n

Aliases: Type less in the CLI

Who likes to type more characters, when we can use git aliases, git does provide a feature called aliases to be configured to use it in git projects across the file system or on a single project.

  • To print the last 15 commits with less info
  $ git config --global alias.l15=log --oneline -15

Use --local option instead of --global to apply these aliases to the individual repo.

  • To fetch with pruning, before fetching, removes any remote-tracking references that no longer exist on the remote
  $ git config --global alias.f=fetch -p
  • List all the files that you have made the changes to and committed to the branch, it will give you a holistic picture on which files are committed part of the commit before pushing to remote.
  $ git config --global alias.list-files=show --pretty="" --name-only HEAD
  • Sort all the branches that you have a created-in descending order with author name and other details. Refer documentation to customize the fields you want to display.
  $ git config --global alias.sort-branch=!"git for-each-ref -- sort=-committerdate refs/heads --format='%(HEAD)%(refname:short)|%(committerdate:relative)|%(subject)'|column -ts'|'"

If you delete the cloned copy after a feature/bug is completed and clone the fresh copy each time you work on a new feature/bug, the above alias is of no use. I prefer using the single cloned copy, create as many features or bug fix branches in the same local copy so that it is easy to look back on history to see which fix/feature went when.

  • Other aliases that I use more frequently
  # pull changes from master
  $ git config --global alias.pom=pull origin master

  # Rebase with master
  $ git config --global alias.rbm=rebase master

  # To get the list of all the global configs for the machine
  # Change it to --local to see a local configuration
  $ git config --global alias.config-list=config --global --list

  $ git config --global alias.cl=checkout -
  •  Use the created alias as follows, git command before the alias name is mandatory
  $ git f
  • If you are on macOS or Linux distribution, you can combine more than one command with short-circuiting to execute the commands sequentially.
  $ git cm && git f && git pom && git cl && git rbm

Above command checks out to the master branch from the current branch, then fetches the remote changes, then pulls the changes from master and merges with the master, then checkout to the last branch point you were in, and finally releases the master changes with the current branch.

See how easy it is to achieve more with less typing.

I recommend you to use the complete commands until you are familiar with them so that you won't forget them because you have aliases defined.

One funny thing that I've noticed with the aliases over the years was when my colleagues were asked me to look at some code that they are working on their machine and I try to use an alias that I'm familiar with but it never worked because they haven't added any aliases with the same name like that one in my machine, later I realized that it is not my machine.

If you want to make sure everyone uses the same config across your team, you can have a meeting with your team and come up with good names for aliases and agree to use the same aliases across the team, please don't force them to use what is convenient for you, that is the reason as to why you should be familiar with actual commands before going for aliases as I've mentioned above.

This is it, for now, I'm going to write few more articles on advanced git topics such as, rebase, reflog, resolving merge conflicts with kdiff3 - a visual tool to merge conflicts.

Please leave a comment if you want me to cover the basics of git or any other topic related to git. Follow me for more technical content related to JS, React, NodeJS, and more.

Please leave a comment, if you know other tips and tricks that you are using every day.

Happy coding.

Posted on by:

kpunith8 profile

Punith K


Loves coding with JS, Java, exploring Python, Dart, and Flutter. Codes with NodeJS, React, Redux, Cypress, HTML, CSS. Knows about REST API's, Testing, Docker, AWS and lot more


Editor guide

Nice tips for Git collated👍🏻