Over the past few years, I’ve delved into the minutia of . Specifically, in , I showed how to create an entire repository from scratch using and low-level commands such as . git and git internals my git internal series echo git hash-object In many instances, understanding the concepts of git can help us know when things go wrong - for example when you do something you didn’t want to do, and you just want to go back in time. I call these git disasters “gitsasters.” I have written a two-part blog series to help you feel confident when things go wrong in git. Here’s what I mean: when someone commits to the wrong branch, they will call you, and you will be able to help out; when a team member loses important changes they have made, you will be the person to consult with. These things happen all the time, and those of us who understand how git works under the hood remain calm and just figure out what’s going on. Those who don’t have this more nuanced understanding of git look at it as a magical black box. Image Source So let’s get started and deepen our understanding of git while acquiring new tools, especially for rewriting history. I will also be applying these tools to real-life scenarios. Recap - recording changes in git I’m quickly recapping the process of recording changes to a git repository which I have also covered in if you want a more thorough overview. a previous post When you work with git, you’ll always have a . A working tree is any directory on your filesystem with a repository associated with it. A is a collection of commits, each of which is an archive of how the project’s working tree looked like at a past date, whether on your machine or someone else’s. It also defines other stuff - like , branches, or tags. working tree repository HEAD Unlike other similar tools you may have used, git does not commit changes directly from the working tree into the repository. Instead, changes are first registered in the index or the “staging area.” You can think of the index as a way of “confirming” your changes, one by one, before doing a commit - which records all the approved changes at once. Think of these states as three different trees - the working tree, the index, and the current commit in the repository. Creating a repo with an initial commit As you can see, I’ve created a repository and created within it a file called , with the content of . 1.txt hello : where is this file now, referring to the three trees I mentioned earlier? Question : It is in the working directory - the same directory with the directory. To confirm that - make sure to use , as it is hidden. Answer .git dir /a Note that is untracked - as git never included this file in its index. 1.txt You can verify that, of course, by using : git status Now let’s add it to the index: Finally, let’s create a commit object to include the file in a commit object in the repository. You’ll notice now that all states are the same: the working dir’s state is the same as the staging area and the same as the current commit of the repository which points to. HEAD You can such as , or , as discussed in . Today, rather than focusing on how these commands are implemented, I’m showing you how to reverse or undo them. create a repository without using porcelain commands git init git add git commit a previous post In the repo I created above, you’ll see your first commit, with the SHA-1 of . Let’s give it the nickname “Commit 1”. e317f16e5b6ce08bc77b36008e10082276b051d4 Now let’s create another commit that will include another new file: The new commit is now in the working directory, and the next step is to add it to the index: Now create a new commit: So this is the current state: Image Source With “git commit,” there are two things to note: You created a new commit object, this time the one with the SHA-1 value of , that we’ll call “Commit 2.0”. c890ca6432c0d54826b941c45a699b8a3c02f4d0 “Git commit” also moved the pointer of the active branch - in this case main - to point to the newly created commit. Note that currently, “Commit 2.0” is also what HEAD points to, and you can verify that using the command : git rev-parse This gives us the SHA-1 of “Commit 2.0”. Don’t forget that you can also use some cool git syntax to refer to commits relative to other commits. For example, if you refer to - you are referring to the direct parent of , which in this example would mean “Commit 1”. HEAD~1 HEAD Let’s verify that here: You can undo your actions using the . The command has three main modes: soft, mixed, and hard. super-powerful command, git reset git reset : step 1 git reset Regardless of the move, the first step of is to move whatever is pointing to. If you use the mode - - it will simply stop there. git reset HEAD soft git reset --soft For example, let’s use . This tells git to move whatever HEAD points to - in this case, the branch -  to point to ’s parent, “Commit 1”. git reset --soft HEAD~1 main HEAD Next, run this command and then use to examine what happened: git log You can see that git goes to , sees that it points to , which now points to “Commit 1”. So the commit we’re calling “Commit 2.0” is not reachable from this history. HEAD main If you’re asking whether it still exists in git, the answer is yes. If you use , you can see that it is still there: the plumbing command git cat-file -p What about ? Let’s check: git status You can see that is now in the staging area. Of course, it is also in the working tree. However, it is not present in the active commit, as you changed the active commit - that is, now points to , which in turn points to “Commit 1”, rather than “Commit 2.0”. 2.txt HEAD main Note that did NOT change . In other words, itself still points to branch. However, what pointed to - the branch - changed. git reset --soft HEAD HEAD main HEAD main In other words, allowed us to undo the last step of introducing changes - using the command. You are now back to where you were before committing, with only one difference: the git commit object has been created and resides within git’s internal database. git reset --soft git commit So this is the current state: Image Source So, if you use , the operation ends here. git reset --soft : step 2 git reset The second step of is to update the Staging Area to be the same as what points to. git reset HEAD To demonstrate, first recreate the last commit: I’ll name this commit “Commit 2.1” as the tree it references is exactly the same as the original “Commit 2”, except that it has a different timestamp and a different SHA-1 value. Now you can use . git reset --mixed HEAD~1 Here’s what’s happening: The first step, now points to “Commit 1”. That’s where stopped. You can see that with : HEAD git reset --soft HEAD~1 git log This looks the same as when you used the switch. --soft The second step: updates the staging area to the snapshot that now points to. Currently, points to , which in turn points to “Commit 1”. git reset HEAD HEAD main Let’s verify that: You can see that now is no longer a part of the staging area. It is, however, a part of the working tree. 2.txt As a result of running , the status of the active commit is the same as the status of the staging area, and they are different than the status of the working tree. Here’s the current state: git reset --mixed Image Source By specifying , stops at this point. This is also the default switch for . --mixed git reset git reset : step 3 git reset In the third step, makes the working directory look like the index (again, I use the terms and interchangeably). If you use the option, then will continue to this stage. git reset index staging area --hard git reset Let’s see how this looks. First, recreate “Commit 2”. This time, you need to add to the index again and then commit. Then, run again: 2.txt git log And of course, is clean, as again the three states are the same - the working tree, the index, and the active commit all look the same: git status Now let’s use . This will first go through the two first steps: git reset --hard HEAD~1 Whatever HEAD was pointing to, in your case - branch, is now pointing to what used to be , that is, “Commit 1”. This is where stops. main HEAD~1 git reset --soft You can see this by using : git log Next, updates the index to be the same as what currently points to after the first step. git reset HEAD So in our example, the index no longer includes the file . That’s where stops. 2.txt git reset --mixed In the third step, updates the working directory to be similar to the index.  In this case, it means the working dir no longer includes the file . You can verify that if you use : git reset 2.txt git status You can also see this by looking directly at the file system: You can see that indeed is no longer there. 2.txt Applying to git disasters (gitsasters) git reset Hopefully now you’re convinced that tool is a superpower for coding. But to really understand why, I want to show you how it can be applied in your daily work, with mini gitsasters. git reset Gitsaster scenario #1 Consider this scenario: you started with the file , which was committed in “Commit 1”. Now you want to create the file , and add and commit it: 1.txt 2.txt Oh, but wait, I forgot one thing: I wanted to write that actually into that file. Swimm is AWESOME Of course, I can just create a new commit and add it to the commit history, but that would mean that this “Commit 2.3” is just a mistake, and I’d much prefer to avoid that. So how can I undo it? One way would be to use . By doing that, you undo the last operation of making point to the new commit: git reset --soft HEAD~1 HEAD I can now make changes to : 2.txt Now you can now add it to the index and commit. As a result, you’ll have a clean history: Gitsaster scenario #2 Here’s another scenario: let’s say you introduce another change by creating another file and then add and commit it: Oops again! You inadvertently committed it to the branch when you wanted the commit to be on another branch - a feature branch. main So your current commit history looks like this: Image Source You actually want your commit history to look like this, where the main branch does not include “Commit 3” - but rather a new feature branch includes it. The desired state: Image Source This is an elementary example, and I can simply just undo the creation of altogether, and then recreate it. But in many instances, you will have already made many changes and introduced them in a commit to the wrong branch. I can assure you that you’ll want to skip making all the changes again when you can just commit to a new branch. 3.txt So let’s use what we’ve learned so far to fix this. Draw the states and consider them carefully. You should remember that what you have here is commit objects and pointers to them and that you can manipulate them using the tools you’ve acquired. Notice that there are three main differences between the states: where points to main the existence of and where it points to feature_branch where points to. HEAD Let’s deal with them one by one. First, you can create . Here’s how: by simply using , you are doing just that by creating a pointer by the name of . It also points to “Commit 3” - which is what you want. feature_branch git branch feature_branch feature_branch Second, change the branch. You want it to point to the previous commit, “Commit 2.4”. To do that, you can just go back in time like this: main Now points to “Commit 2.4”. Notice that the state of the index and the working directory have been changed to match the state of “Commit 2.4”. main The current state. Image Source Very cool, if I say so myself 😎😎. What is left to do is to update to point to your . To do this, you can simply use : HEAD feature_branch git checkout And so - you have reached the desired state! How cool is that? By using , as well as simple commands such as or , you can change the repository’s state to precisely what you want it to be. git reset git checkout git branch Gitsaster scenario #3 Let’s consider one final scenario by introducing two changes together. First, create a file by the name of , and change the contents of the existing . You will commit these two changes together: 4.txt 3.txt As a result, you now have a new commit with a clean status: Another oops - cause you didn’t want these two changes to be introduced in a single commit! You can now use the tools we have acquired here to split your changes into two, separate commits. Here’s how:  you can undo the last commit by using . For this case, the most convenient way would be to use the switch: git reset --mixed So now the repository is back to where it was, with “Commit 3” being the last one. Also, the index resembles “Commit 3” yet the working dir includes your changes. You can now add them to the index and commit them separately: Now you have two separate commits: Again, you were able to use to easily modify your history and match the state you want it to be. git reset If you’re sighing a relief to know how to do this, I’m very much with you on this one! Bottom Line Let’s pause and summarize: you now have experience with the command , together with its three modes: git reset , that moves whatever is pointing to --soft HEAD , that goes on to update the index to what is pointing to after the step --mixed HEAD soft , which updates the working dir to match the state of the index. --hard In addition, in applying your knowledge to a few git disaster scenarios, I hope you have a better understanding of how git works and feel way more confident fixing cases where you really need to rewrite some code history without it being a huge headache. Here’s a sneak peek at my next post: you’ll acquire additional tools to deal with gitsasters, including learning how to undo cases where you regrettably push your changes to the remote and/or you regrettably use to rewrite history. git reset --hard If you have not yet had a chance to check out , I encourage you to have a look. and there’s a who are benefiting from via Swimm. Swimm’s platform Swimm’s beta is free growing community of users around the world Continuous Documentation Also Published here

Slack

Super

SuperPower

Webpack to Vite: Improving Speed and Performance

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

How to Avoid Git Disasters (Gitstasters) Part 1: Git Reset

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Webpack to Vite: Improving Speed and Performance

A Look At the Ultimate Commit

Doing Quick Experiments In Git

How to Build a User Management Solution with ORY Oathkeeper and Auth0

How to Clean Your Git History

Webpack to Vite: Improving Speed and Performance

A Look At the Ultimate Commit

Doing Quick Experiments In Git

How to Build a User Management Solution with ORY Oathkeeper and Auth0

How to Clean Your Git History

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps