<i>Git reset</i> is the command that allows you
to shape history in your repository.

Whether you're undoing some changes
or crafting your commits differently,

this is the command for you.

♪ (bossa music) ♪

Welcome to the episode of Git
and GitHub Foundations

on the <i>reset</i> command.

This command has a lot of power,
and a lot of modes.

Yeah, there's going to be three modes
we're going to be working with here.

There's going to be <i>soft</i>;
<i>mixed</i>, or the default; and <i>hard</i>.

♪ (music) ♪

These adjectives are pretty descriptive,

starting with the one
that's the default, <i>mixed</i>.

It alters both the history
as well as the working directory.

So mixed, both things.

And <i>soft</i> is going to take
one or multiple commits

and put all of their changes
back into the staging area

to allow you to continue to craft
a new commit out of that.

<i>Hard</i>, on the other hand,
is a destructive operation

that's meant to erase things
that you no longer wish to keep.

So with all three of these in our stable,

let's look at <i>mixed</i> first.

<i>Mixed</i> is the recommendation

that gets most often shown
to new Git users

because it shows up
in the <i>status</i> command.

When you have changes
in the staging area

and you say <i>git status</i>,
we see <i>git reset HEAD</i>.

That allows us to take those changes
out of the staging area

and put them back
into the working directory

with the <i>mixed</i> option.

<i>Soft</i> is the way
that I take some changes

that might have gotten
too granular in nature.

One, two, three, four, five commits

that I then realize all belong
in one transaction,

and to bring them all together

by a <i>git reset --soft HEAD~5</i>

the most recent five commits.

So with that command of using <i>soft</i>

you can take
all five of those commits

and kind of squash them down
into the staging area as one commit.

Pretty useful for reshaping history,

but reshaping history goes
to the far end of the spectrum

to throw away commits
that just don't add value.

You don't want to send them,
transmit them, or share them with others.

That's where <i>hard</i> comes into play.

If you completely want to throw away
some of your work,

maybe you're trying out some change
that just didn't work out,

you can use the <i>git reset --hard</i>
to throw those commits away completely.

People might ask, then why
would you make a commit?

But Git provides you
a really nice safety net

through the <i>reflog</i> command
that we'll look at in a future episode

that motivates you to make
checkpoints with commits,

and knowing that you have
<i>hard</i> at your disposal,

you can clean that history up
anytime you like.

♪ (music) ♪

There is one other cousin command
that is often talked about with <i>reset</i>

and that's the <i>checkout</i> command.

The <i>checkout</i> command
is of a different granularity than <i>reset</i>,

which typically operates
on the entire history of a repository.

<i>Checkout</i> is focused more
on a directory or a file level precision.

Instead of undoing or changing
an entire commit,

we can go back in history
to a specific file at a commit

and pull that file and its version
back to our current working directory.

Clear communication is the goal
of all Git repository history.

So whether it's <i>git reset hard,
reset soft, reset mixed</i>,

or the more precise <i>checkout</i> command,

use these to provide clear intent
about your changes to your colleagues.

<i>Git reset</i> is a tool that can be
a little bit intimidating

to new users of Git.

But it can be a powerful tool
to have at your disposal

for crafting beautiful repository history.

Thanks for watching another episode
of Git and GitHub Foundations on <i>reset</i>.

As always, don't forget to subscribe
to any of our channels on the side here.

Questions or comments,
put those down below

or check out one
of our other educational topics

on Git and GitHub
here at the bottom.

♪ (music) ♪
(voices silenced)