Git Commands they don't talk about 😼

So I just started working in a corporate tech environment, and what they say is true: Github is the heart of collaborative project handling. So, knowing the basic ins and outs of this wonderful tool is essential.

But this post is not for the basic push-pull commands that we commonly used.

We face scenarios when we have to use other commands to get the job done. These cases might not occur often, but knowing them helps.

1. switch

   A large project will always have multiple branches serving varied purposes: main branch, feature branch, release branch etc. So switching between these branches becomes necessary all the time.

   git-checkout is often the preferred option. But this command is also used for many other scenarios.

   Did you know there is a branch specifically for switching between branches?

   References:

   1. https://stackoverflow.com/questions/57265785/whats-the-difference-between-git-switch-and-git-checkout-branch

   2. https://www.atlassian.com/git/tutorials/using-branches/git-checkout

    git switch <branch>

1. stash

   This command helps us to stash all the committed and uncommitted changes and saves them for later use + reverts them from the working copy.

   Hence, with a fresh working copy, you can make new changes: new commits, switch branches, and perform any other Git operations; then come back and re-apply your stash when you're ready. You put them back in your working copy using the git stash pop command.

    git status
    #shows a bunch of committed + uncommitted changes
    git stash
    git status
    #no unstaged + staged info shown
    ...
    ...
    #you made a bunch of changes above and now wish to bring back your stashed changes
    git stash pop
   

   References:

   1. https://www.atlassian.com/git/tutorials/saving-changes/git-stash#:~:text=The%20git%20stash%20command%20takes,for%20commit%3A%20modified%3A%20index.

2. rebase

   Often when working on a repository, when a bug crops up you may make a new branch from the main branch and work on the changes in the new branch. Later, when you are ready to merge the branch to the main, the main branch may have had its own set of commits too.

   In such cases, git rebase helps to add my commits in my branch to the HEAD of the main branch as entirely new commits.

   A big advantage of rebase over our normal merge command is that it makes sure that the branch I worked on is deleted and the merging of the new commits to the main branch is less messy.

   But another downside is that all the history regarding the commit is overwritten by new history, which may result in a serious loss of metadata. And the chances of showing merge conflicts are also removed when using rebase.

    #there are 2 branches Feature and Main with their own commits as per the diagram below 
    git switch Feature
    git rebase Main 
    #Note that we are rebasing to Main while being in Feature branch
   

   

   References:

   1. https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase

   2. https://www.atlassian.com/git/tutorials/merging-vs-rebasing

3. revert

   This is a useful + preferred command over git reset.

   This command undoes changes by adding new commits that would undo the previous commit changes. Hence maintaining the history of the previous commit + undoing commit changes.

    git revert <commit-log>
   

   References:

   1. https://www.atlassian.com/git/tutorials/undoing-changes/git-revert#:~:text=The%20git%20revert%20command%20is%20a%20forward%2Dmoving%20undo%20operation,in%20regards%20to%20losing%20work.

   2. https://www.datacamp.com/tutorial/git-reset-revert-tutorial

4. blame

   So often while working on large codebases, it gets important to know who added a certain line or comment, to approach the person regarding the reason behind the code change. In such situations, git blame is the perfect command to be used.

   Often you'll also notice git blame-like functionality being available in IDEs like IntelliJ.

   References:

   1. https://www.atlassian.com/git/tutorials/inspecting-a-repository/git-blame#:~:text=The%20git%20blame%20command%20is%20used%20to%20examine%20the%20contents,with%20various%20command%20line%20options.

    #find the author by line numbers
    git blame -L <starting line>,<ending line> <filename>