DEV Community

Cover image for 8 underrated git commands every programmer should know (not the usual pull, push, add, commit)
milindsoorya
milindsoorya

Posted on • Updated on • Originally published at milindsoorya.co.uk

8 underrated git commands every programmer should know (not the usual pull, push, add, commit)

I will be adding more useful git tips, if you find this helpful I suggest bookmarking this page. πŸ”–

1. Rename a local branch

useful when you mess up the branch name with some typos.

// Note: no need to include < >, separate words with -
git branch -m <new_name>
eg:- git branch -m new-new-branch
Enter fullscreen mode Exit fullscreen mode

2. Change the upstream branch

use this to push the local branch to a new remote branch.

git push origin -u <new_name>
Enter fullscreen mode Exit fullscreen mode

3. Makes local branch same as remote

At times we may make many changes to our local branch and end up with something that is worse than what we started with, don't worry everyone has been there πŸ˜…. This command will be helpful in those scenarios.

// replace staging with the branch you want to reset to
git reset --hard origin/staging
Enter fullscreen mode Exit fullscreen mode

4. Delete the most recent commit, keeping the work you've done

I am amazed that not too many people know of this command, this will help to recover from those stupid typos that creep into our commits.

git reset --soft HEAD~1
Enter fullscreen mode Exit fullscreen mode

5. Delete the most recent commit, destroying the work you've done

Use this command when you know you really messed up. don't fret it's part of the journey.🎯

git reset --hard HEAD~1
Enter fullscreen mode Exit fullscreen mode

6. Stash your work

Stash command is used to temporarily work on another branch without committing our current work.

git stash
Enter fullscreen mode Exit fullscreen mode

7. Recover stash by going into that branch and

git stash apply
Enter fullscreen mode Exit fullscreen mode

please note that git stash apply won't delete the stashed item from the stash list. If you want to recover stash and drop it from the stash list use git stash pop.

8. Go back to a previous commit, undo a rebase

It is quite natural to mess up a rebase, these commands will hopefully save you. use reflog command to find the head number of the required commit you want to reset to.

// Find the head at that point
git reflog 

// Replace 5 with the head number, please be extra careful not to 
// give wrong wrong head number
git reset --hard "HEAD@{5}"
Enter fullscreen mode Exit fullscreen mode

πŸ‘‰πŸΌ checkout my website, milindsoorya.co.uk for more updates and getting in touch. cheers.

Thank you very much for reading, liking and commenting on my articles. If you have enjoyed my article or if it was helpful please support me by buying me a coffee β˜• πŸ˜‡.

Top comments (9)

Collapse
 
dentych profile image
Dennis • Edited

Hmm.. I'm a little split regarding this article.
It's nice to see an article that's not "how to commit and push". However, some of these seems a little unnecessary.
I have a few comments:

  1. git push origin -u <branch> does not rename anything. It pushes the local branch and sets the upstream for remote tracking.

  2. --soft is the standard setting for git reset (and thus is not needed). HEAD~1 is the same as HEAD^, which is easier to write.

  3. Same comment as above regarding HEAD^

  4. git stash apply will not remove the stashed item(s) from the stash list. Using git stash pop will apply the stash and then remove it from the stashed items list. If you use apply, you will manually have to drop the stashed item afterwards, as in 99% of the cases you will not want to keep the stashed items after they've been reapplied to the current branch.

  5. This just seems unnecessarily cumbersome. You can just do git log, find the commit you want to reset to and do git reset --hard <sha>. You would also be able to just do git reset --hard origin/branch, as in most cases you wouldn't have pushed. Using HEAD@{xx} is entirely unnecessary, in my opinion, as you can use git shas, branch names and other things that makes more sense.

Collapse
 
chaelcodes profile image
Rachael Wright-Munn

2 & 3 - it's better to get comfortable with HEAD~1, because you can HEAD~2. If you only learn HEAD^, then you only learn to go back 1 commit.

5 works post-rebase. git log does not.

Collapse
 
dentych profile image
Dennis • Edited

You can do HEAD^^^^^ to go back 5 commits, so in reality it's the same. I find it easier to write ^, but it's really up to personal preference :)

5 works fine post-rebase. git reflog can be very confusing for newbies, because it shows a log of where the HEAD has moved, and not just a (probably) fairly linear commit history.

Collapse
 
milindsoorya profile image
milindsoorya

Reading the post again the second point does feel a bit misleading . Made some changes to make it clearer and thanks for the comment, appreciate it.

Collapse
 
dentych profile image
Dennis

I like 2 better now :)

And I'm glad you took the comment as well-meant feedback!

Overall, a fine post :)

Collapse
 
martinhaeusler profile image
Martin HΓ€usler • Edited

git clean -xdf is a great "sh*t hit the fan" command. It erases each and every file in your git directory which is NOT part of your repository. All additional files, such as the ones listed in your .gitignore, will be removed. It's a useful one when you need a fresh start, usually used in conjunction with git reset --hard. Be careful when you use it in projects where external dependencies are downloaded into your projects folder (looking at you, node_modules!) because you'll have to re-download everything again.

Collapse
 
milindsoorya profile image
milindsoorya

I guess git clean -xdf is something in the line of "with great power...".πŸ˜…Thanks for sharing.

Collapse
 
jidicula profile image
Johanan Idicula • Edited

git bisect for regression-hunting git-scm.com/docs/git-bisect

Pick a known-good commit, then a known bad commit, and Git does a binary walk between those commits, with each step pausing at a commit and allowing you to check for the regression. Eventually (in log2(n) steps for n commits), you'll be left with the commit where the regression was introduced.

Collapse
 
milindsoorya profile image
milindsoorya

Woow, this is pretty cool 🀯.