{"id":22450,"date":"2020-09-11T06:48:55","date_gmt":"2020-09-11T13:48:55","guid":{"rendered":"https:\/\/careerkarma.com\/blog\/?p=22450"},"modified":"2020-12-29T12:36:05","modified_gmt":"2020-12-29T20:36:05","slug":"git-reset","status":"publish","type":"post","link":"https:\/\/careerkarma.com\/blog\/git-reset\/","title":{"rendered":"Git Reset To The Rescue"},"content":{"rendered":"\n

When you are working on a project by yourself or as part of a team, there might be instances when you want to undo a commit. The git reset <\/code>command is one of the tools known to be a real lifesaver.<\/p>\n\n\n\n

Git’s Tracking Mechanism<\/strong><\/h2>\n\n\n\n

Before going to git reset<\/code>, we need to understand about the underlying structure of git. Git manages and tracks files, through tree-like structures with nodes and pointers. <\/p>\n\n\n\n

There are basically three of these “trees” on your local git repository:<\/p>\n\n\n\n

  1. The Working Directory<\/strong>: Or working tree, and it refers to your local directory and git status<\/code> will give you the state of your working directory.<\/li>
  2. HEAD<\/strong>: Is just your current branch’s last commit snapshot. If you were to switch branches with git checkout<\/code> then the HEAD will change to the last commit on the branch.<\/li>
  3. Index<\/strong>: Or staging<\/strong> area. So when you git add<\/code> files to commit it adds them to this index.<\/li><\/ol>\n\n\n\n

    Git Workflow<\/strong><\/h2>\n\n\n\n

    The following example shows making changes to a file and then adding it to index (staging) using git add<\/code> then checking git status<\/code> to see changes to be committed.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    <\/p>\n\n\n\n

    Now when we do git commit<\/code> it saves as a more permanent snapshot and updates the master and HEAD to that pointer. So if we do git status<\/code> after git commit<\/code>, we’ll see that all three trees are in the same state (there will be nothing to commit).<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    So what’s the purpose of <\/strong>git reset<\/strong>?<\/h3>\n\n\n\n

    You might be wondering why all this preamble just to get to git reset<\/code>. Well git reset<\/code> manipulates these trees in different ways. So git reset will accept a variety of options depending on what you want to do.<\/p>\n\n\n\n

    Git Reset Modes<\/strong><\/h2>\n\n\n\n

    Let’s say we committed some changes and files, then to realize we committed them to the wrong branch or our commit is buggy so we want to rewind. Here’s where knowing about the git reset modes<\/strong> is useful.<\/p>\n\n\n\n

    All git reset with mode will update the HEAD pointer. It has the following syntax <\/p>\n\n\n\n

    git reset <mode> <commit-optional><\/code><\/p>\n\n\n\n

    The main modes are:<\/h2>\n\n\n\n