{"id":1813,"date":"2024-08-06T21:51:00","date_gmt":"2024-08-06T18:21:00","guid":{"rendered":"https:\/\/mshaeri.com\/blog\/?p=1813"},"modified":"2025-07-14T09:50:05","modified_gmt":"2025-07-14T06:20:05","slug":"git-commands-you-should-know","status":"publish","type":"post","link":"https:\/\/mshaeri.com\/blog\/git-commands-you-should-know\/","title":{"rendered":"Git Commands You Should Know"},"content":{"rendered":"\n

As developers, we all rely on Git in our daily tasks. However, many of us only use basic commands of Git like committing, pushing, or pulling! But Git <\/strong>has evolved significantly over the years, introducing powerful new features that can really simplify your complex workflow. They can make our life a whole lot easier and help us work more efficiently. Ready to level up your Git game? Let\u2019s go! \ud83d\ude80<\/p>\n\n\n\n

1. ORIG_HEAD , Your Lifesaver<\/h2>\n\n\n\n

Have you ever found yourself in a frustrating situation where, after rebasing <\/strong>your branch with another one and battling through a mountain of conflicts, you end up with a messy codebase that doesn\u2019t resemble either the base or the current branch? And to top it off, it doesn\u2019t even work the way it\u2019s supposed to? Trust me, I\u2019ve been there too!
That\u2019s exactly why I decided to dig deep and find a little trick to help us get back to where we were before that chaotic rebase<\/strong>.
Here\u2019s the magic command:<\/p>\n\n\n\n

  git reset --hard ORIG_HEAD<\/code><\/pre>\n\n\n\n
In fact, ORIG_HEAD<\/strong><\/code> is like a safety net in Git. Whenever you perform certain actions, like a rebase<\/strong>, reset <\/strong>or a merge<\/strong>, Git records the position of the HEAD <\/strong>before those operations. ORIG_HEAD <\/strong>points to the commit that was your HEAD <\/strong>(the current commit you\u2019re working on) before the last operation. It\u2019s a handy little reference that can save your day when things go sideways!

So , when you run git reset --hard ORIG_HEAD<\/mark><\/code>, you\u2019re telling Git to reset your current branch. This means you\u2019re moving your branch pointer back to the commit that ORIG_HEAD <\/strong>is pointing to. In simpler terms, you\u2019re undoing the rebase <\/strong>and going back to the state you were in before all the conflict resolution and messy code.  The –hard<\/strong> option means that any changes in your working directory and staging area will be lost. So, make sure you really want to go back to that previous state because this command is a bit like hitting the reset button!<\/p>\n\n\n\n
In short, this command is a lifesaver when you find yourself in a coding pickle after a rebase<\/strong>. Just remember to use it wisely, and you\u2019ll be back on track in no time.<\/p>\n\n\n\n
2. worktree, A Productivity Booster<\/h2>\n\n\n\n
Many times we had to work on multiple branches in a single repository at the same time. For example, we\u2019re deep into a feature request when a critical bug pops up that needs our immediate attention. It can be a bit of a juggling act, right?
In these situations, we usually have two options: either clone multiple versions or branches of the repository, or stash\/discard away what we were working on. But don\u2019t worry, there\u2019s a better way to handle this. Here\u2019s a quick example to show you how it works:<\/p>\n\n\n\n
git branch\n# * dev\n# master\n\ngit worktree list\n# \/...\/some-repo  ews5ger [dev]\n\ngit worktree add -b hotfix .\/hotfix master\n\n# Preparing worktree (new branch 'hotfix')\n# HEAD is now at 5ea9faa Signed commit.\n\ngit worktree list\n# \/...\/test-repo         ews5ger [dev]\n# \/...\/test-repo\/hotfix  5ea9faa [hotfix]\n\ncd hotfix\/  # Clean worktree, where you can make your changes and push them<\/code><\/pre>\n\n\n\n
With this command, you can have multiple branches of the same repository open at the same time! In the example above, we have two branches: dev <\/strong>and master<\/strong>. Let\u2019s say you\u2019re busy working on a feature in the dev <\/strong>branch, but then you get a request to fix a bug urgently. Instead of stashing your changes and resetting your branch, you can simply create a new worktree <\/strong>in the .\/hotfix subdirectory based on the master branch.
Once you\u2019re in that directory, you can make your changes, push them, and then head back to your original worktree <\/strong>without missing a beat! You can check out this article<\/a> for a more detailed explanation. <\/p>\n\n\n\n
<\/p>\n\n\n\n
3. switch, Instead Of checkout<\/h2>\n\n\n\n
Since 2019, specifically with the release of Git version 2.23, we now have a handy command called git switch<\/strong><\/code> that makes switching branches super easy! To switch to another branch, just type:<\/p>\n\n\n\n
 git switch other-branch<\/code><\/pre>\n\n\n\n
If you want to hop back to your previous branch, you can simply use:<\/p>\n\n\n\n
  git switch -<\/code><\/pre>\n\n\n\n
It\u2019s kind of like using cd – to go back to your last directory! <\/p>\n\n\n\n
And if you want to jump straight to a remote branch and start tracking it, you can do:<\/p>\n\n\n\n
  git switch remote-branch<\/code><\/pre>\n\n\n\n
Pretty cool, right? But you might be wondering, \u201cWhy do we need this new command when we\u2019ve been using git checkout<\/code><\/strong> to switch branches all along?\u201d Good question!
While git checkout<\/strong><\/code> is a super versatile command that can do a lot of things\u2014like checking out specific files or even restoring specific commits\u2014git switch<\/strong> is focused solely on switching branches. Plus, git switch<\/strong><\/code> includes some extra safety checks that checkout doesn\u2019t have. For instance, if switching branches would cause you to lose any local changes, git switch will stop you in your tracks, which is pretty handy!
So, if you\u2019re looking for a simpler way to switch branches, give it a try! 

Happy coding! \ud83d\ude80<\/p>\n","protected":false},"excerpt":{"rendered":"
As developers, we all rely on Git in our daily tasks. However, many of us only use basic commands of Git like committing, pushing, or … <\/p>\n","protected":false},"author":1,"featured_media":1815,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[203,1,202,231,35],"tags":[232,9,235,237,15,39,234,236,233,239,238],"_links":{"self":[{"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/posts\/1813"}],"collection":[{"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/comments?post=1813"}],"version-history":[{"count":5,"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/posts\/1813\/revisions"}],"predecessor-version":[{"id":1911,"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/posts\/1813\/revisions\/1911"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/media\/1815"}],"wp:attachment":[{"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/media?parent=1813"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/categories?post=1813"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mshaeri.com\/blog\/wp-json\/wp\/v2\/tags?post=1813"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}