Imagine this: your client asks you for a new feature. You work on it solidly for two days, and he changes his mind in the end.
Disaster!
You’ve wasted two days developing a feature for nothing, and what’s more, you now have to find a way of going back to where you were before! Luckily, our friend Git comes to the rescue with the command git reset
!
The Three Types of Git Reset
The command git reset
is a complex and multifunctional tool to undo changes. It can be used in three different ways, which correspond to the command line arguments --soft, --mixed and --hard.
Let’s start with reset --hard
.
Run the command:
git reset OurTargetCommit --hard
This command can take you back to any commit you want but wipes absolutely everything done after it! When I say everything, I mean EVERYTHING! Any changes or other commits made afterward will all be deleted! This is why it’s crucial to check several times before launching it, as you could lose all your changes if you get it wrong.
Using git reset
is a simple way of canceling changes that haven’t yet been shared. This command is incredibly useful when you’ve started working on a feature, made a mistake, and want to start again from scratch. The command git reset --mixed
allows you to go back to where you were just before your last commit, or any specific commit, without deleting the changes you’re working on. You can also use it to unstage files for files that have been staged but not yet committed.
git reset HEAD~
If nothing is specified after git reset
, a git reset --mixed HEAD~
will be launched by default.
It’s a bit like your shadow—it follows you wherever you go! By default, HEAD points to the current branch, main/master, but can be moved to another branch or another commit.
Finally, there’s git reset --soft
. With this command, you can go to a specific commit to see the code at a given moment or create a branch based on an old commit. It doesn’t delete any files or commits, nor does it create a detached HEAD.
Oops, You’ve Got Conflicts!
In the second part of this course, you saw how to merge branches, using a simple example where everything worked as it should. Unfortunately, sometimes (actually quite often), things don’t work out so well, and you end up with conflicts.
Going back to the example from the beginning of the course, let’s say you’ve been working on a branch called “fundingPotImprovement.” However, there are already files corresponding to improvements made to the Funding Pot feature on the main branch, and you’re changing lines that are already in place.
You’ve changed the code to show the message “A great funding pot!”—except that there was already another message in place: “A funding pot.” This makes for a tricky situation when you try to merge the two branches:
git checkout main git merge fundingPotImprovement Auto-merging FundingPot.php CONFLICT (content): merge conflict in FundingPot.php Automatic merge failed; fix conflicts and then commit the result
Git will see that you’re trying to merge two different things on the same line, but it won’t know which to use between “A funding pot” and “A great funding pot!” It’s clever, but not telepathic! Therefore, Git will show a conflict in the file FundingPot.php and stop the merge process. You’ll then have to resolve the conflict by opening the file with your usual editor:
<<<<<<< HEAD A funding pot ======= A great funding pot! >>>>>>> fundingPotImprovement
You can resolve the conflict by comparing the two lines and choosing which change you want to keep. Here, we want to keep “A great funding pot!”, so we’re going to delete the other lines and only keep this:
A great funding pot!
Now you’ve resolved the conflict, you just need to let Git know!
git add FundingPot.php git commit
Git will detect that you’ve resolved the conflicts and will suggest a commit message for you. Of course, you can change it if you want.
You’ve Added the Wrong File to a Commit
It’s just mistake after mistake! This time, you’ve made a commit, but the wrong file somehow got into it! Don’t worry; Git has a handy time-travel feature! The command git revert takes you back to the previous state while making a second commit. Instead of deleting the commit from the project history, it works out how to undo the changes made by the commit and adds a new commit with the content obtained in this way. It takes you back to the previous state but with a new commit. This means that Git doesn’t lose its history, which is important for your revision history and reliable conditions when working with others.
What’s the difference between git reset and git revert?
git reset
takes you back to the previous state without creating a new commit, while git revert
creates a new commit.
Try out this useful command by making a first commit that you’re going to decide you don’t want. Once you’ve made this commit, type the following command:
git revert HEAD
Once your commit has been deleted, you can remove your file and make your commit again.
Let’s Recap!
git reset is a powerful command. There are three different ways of applying it (--soft, --mixed, --hard).
The command git merge leads to a conflict if the same line has been changed several times. In this case, you need to tell Git which line to keep.
Using
git reset
, you can go back to the previous state without creating a new commit.Using
git revert
, you can go back to the previous state by creating a new commit.
In the next chapter, you’ll see how to correct a commit that’s gone wrong!