2Git, the concept

Recovering data from a previous commit point can be accomplished by using the reset command.

Reset—a word of warning
Reset is the process of switching a project to a previous commit point.
RESET IS A VERY CONFUSING ASPECT OF GIT, IT’S A RIGHT BASTARD TO UNDERSTAND

There are three types of reset: soft, mixed and hard. The differences are to do with what happens to files in the working directory and staging area.

I will explain all of them, but before I do, I need to set up a project by way of an example that we can work with:

The easiest type of reset to understand is the hard reset; it resets a project back to an earlier commit and replaces all the files in the working directory with the files that were present at the time of the specified commit.

To explain this let’s consider a simple project with just one file (test.txt). I will go through modifying the file and creating commits in a step-by-step way to demonstrate exactly what happens with a reset.

Let’s assume we have a new project and we’ve just created a new file called test.txt. This file is present in the working area only, we haven’t added or committed the file yet (step 1). Next add the file to the staging area (step 2) and then commit it to the local repository (step 3):

	Action	Result
	Step 1
	In a new repository create the file test.txt and add some text to it. This is now in the working area and is version V01 of the file.
	Step 2
	Add the file to put it in the staging area.
	Step 3
	Now commit the file to the local repository.

This gives our first commit [ac452db].

Now let’s modify the test.txt file (making it V02) and repeat the add and commit process to give our second commit [5493a7c] (step 4).

	Action	Result
	Step 4
	Modify text.txt. It is now V02. Now add and commit the file to the local repository.

Now we do it all again for a third commit [22af5b5] and a file at V03 (step 5).

	Action	Result
	Step 5
	Modify text.txt again. It is now V03. Now add and commit the file to the local repository to give 3 commits in total.

• Some of you may be wondering why I show files in the staged area after a commit, when in Figure 2.7 to Figure 2.10 I showed it as empty. In practice, the staged area does still hold the files (I showed it as empty to make the explanation easier to understand).

The staged area always holds the files, but if they are the same as the committed files, Git considers it to be empty—it isn’t, but there is nothing in there that requires action.

Finally, let’s modify the working copy of test.txt (making it V04) and add it to the staging area (step 6). Do not commit these changes; this is work in progress and I will use it to show how the different types of reset work. We have this as the final step:

	Action	Result
	Step 6
	Modify text.txt again. It is now V04. Now add and commit the file to the staged area.

I’ve shown the modified and staged file version in red.

Now let’s look at what a reset does.

Reset—a reassuring point
The reset process can be destructive; it can overwrite data (it’s one of the few things that Git does that can lose your data). That said:
A reset will never change or delete committed data. Committed data is always safe, a commit point will never be deleted and you can always go back to it. The worst a reset can do is overwrite changes in working or staged files.

I will start with a hard reset; like a hard Brexit, it’s the option that makes most sense.

Ok, we now have a project with three commits in it. The head is on the master branch and is at the latest of those commits [22af5b5]. All well and good, this is just exactly the same as the example we worked through in the previous section.

We’ve also got a modified working copy file that has also been staged but not committed (step 6 above).

A reset (any reset) moves the head to a different commit point (a bit like switching branches). A hard reset overwrites the files in the working and staged areas with the files from the commit point that we are resetting to.

This is a bit like going back in time and accidentally killing your own father before you were born—it leaves things hanging.

Currently we are at step 5 and our commit history is:

	[22af4b5]	Version V03
	[5493a7c]	Version V02
	[ac452db]	Version V01

Now hard reset back to commit point [5493a7c] just like we did in the previous section—we get exactly the same result:

	Action	Result
	Reset (hard) to [5493a7c]. Head moves to a different commit point. This overwrites the staged and working areas with the files from the [5493a7c] commit point.

The history shows:

	[5493a7c]	Version V02
	[ac452db]	Version V01

It’s not showing the [22af4b5] commit point.

This makes sense, the history only includes things up to the current head point.

We can still move back to the [22af4b5] commit point because we did in the previous section. The problem is what if we make changes at this earlier commit point?

Do it, modify test.txt this time we’ll call it V05—like the shampoo (I used V04 before remember)—commit the changes, this is commit [8f46c7b].

	Action	Result
	Modify text.txt again, it is now V05. Now add and commit the file to the local repository.

And now if we look at the history:

	[8f46c7b]	Version V05
	[5493a7c]	Version V02
	[ac452db]	Version V01

Commit point [22af4b5] isn’t there. A bit like Stalin, we’ve rewritten history.

The missing commit point is still there^†1, it no longer fits into the chain of commits—it’s just floating around in the Git repository.

It’s perfectly possible to switch to the missing commit point [22af4b5]. If we were to reset to it [22af4b5] we would have:

	Action	Result
	Reset (hard) to [22af4b5].

The commit history being:

	[22af4b5]	Version V03
	[5493a7c]	Version V02
	[ac452db]	Version V01

Confusing isn’t it?

†1		You need to be careful with these floating commit points, they are deleted when the database is cleaned up (pruned in Git terminology—it’s gardening, like branches).

I don’t like the idea of resetting to a previous commit point and then progressing on from there as if nothing had happened (effectively bypassing the later commits).

Let’s assume that we’ve progressed from step 1 to step 5 in the previous example and we haven’t done any resets (i.e. commit [8f46c7b] never happened). We have this:

	Action	Result
	Step 5
	text.txt is at V03; there are no changes pending.

Let’s also assume that there is some problem with test.txt and we realise that the version we need is actually version 01 with some slight modification. The best procedure to recover V01, modify it and commit the modifications is as follows:

Let me say now, a hard reset is the only one to use.

Boy am I goanna get some emails—they’ll all be from Linux people, they usually are^†2.

My rules for resetting:

1. Always commit or delete modified files before resetting

2. Always use a hard reset

3. Resetting a project should only be done to view the files as they were at that point in time, never to modify them

4. Never modify files at any commit point other than the latest (most recent) commit (on a given branch)

That said I will explain what the other types of reset do—I just haven’t figured out what they are for.

The first one is a mixed reset. This is the default type of reset applied by Git.

Set up the project as it was in § 2.5.1 step 6. It looks like this:

	Action	Result
	Step 6
	The most up to date commit has text.txt at V03. he working and staged areas hold a modified version of text.txt at V04.

I refer you to the comments I made about the mixed reset in the previous section.

A soft rest does even less; all it does is move the head.

Set up the project as it was in § 2.5.1 step 6. It looks like this:

	Action	Result
	Step 6
	The most up to date commit has text.txt at V03. he working and staged areas hold a modified version of text.txt at V04.

My rules and notes for resetting are:

1. A reset will never change or delete any committed data or commit points

2. Always make a note of the latest commit number (hash)^†3

3. Always commit modified files before resetting

4. Always use a hard reset

5. Resetting a project should only be done to view the files as they were at that point in time, never to modify them

6. It’s ok to copy files from an earlier commit (following a hard reset) and paste them into the latest commit point (ensure you explain it in the commit message)

7. Never modify files at a commit other than the latest (most recent) commit (on a given branch)

†3		I say this because if you reset to an earlier commit, the later ones don’t show up in the history and this makes it harder to get back to a later commit if you don’t know its commit number. There are ways around this, see § 7.2.1).