WEBVTT

99:59:59.999 --> 99:59:59.999
<i>Git Rebase</i> is the ability
to take existing commits,

99:59:59.999 --> 99:59:59.999
and to place them on a branch
that starts today.

99:59:59.999 --> 99:59:59.999
♪ (jazzy theme music throughout) ♪

99:59:59.999 --> 99:59:59.999
Creating a branch is a tough decision.

99:59:59.999 --> 99:59:59.999
Start it today, or start it later?

99:59:59.999 --> 99:59:59.999
Well, some important fixes
might be happening right now.

99:59:59.999 --> 99:59:59.999
So better wait until tomorrow.

99:59:59.999 --> 99:59:59.999
That difficult decision
has gone away with <i>Git</i>.

99:59:59.999 --> 99:59:59.999
Start a branch whenever you like,

99:59:59.999 --> 99:59:59.999
and make it contain the changes
that you intend to deliver.

99:59:59.999 --> 99:59:59.999
Focused on a particular feature,

99:59:59.999 --> 99:59:59.999
bug fix, or objective.

99:59:59.999 --> 99:59:59.999
What about wanting this to start

99:59:59.999 --> 99:59:59.999
at a later place in history,

99:59:59.999 --> 99:59:59.999
in order to incorporate those hot fixes

99:59:59.999 --> 99:59:59.999
that are going on to the master branch?

99:59:59.999 --> 99:59:59.999
No problem.
<i>Rebase</i> to the rescue.

99:59:59.999 --> 99:59:59.999
<i>Rebase</i>, in its standard usage form,

99:59:59.999 --> 99:59:59.999
allows one branch to be relocated
farther down the history track,

99:59:59.999 --> 99:59:59.999
meaning taking all of the changes
that are isolated on your branch,

99:59:59.999 --> 99:59:59.999
and acting as if they happened <i>after</i>

99:59:59.999 --> 99:59:59.999
all of the modern work
on the master branch.

99:59:59.999 --> 99:59:59.999
This accomplishes the same thing,
but with cleaner history,

99:59:59.999 --> 99:59:59.999
than doing a reverse merge

99:59:59.999 --> 99:59:59.999
from the master branch
to the feature branch.

99:59:59.999 --> 99:59:59.999
The same contents will be present
in the feature branch,

99:59:59.999 --> 99:59:59.999
but without the complication of the merge,

99:59:59.999 --> 99:59:59.999
going into that feature branch,
and recorded in its history.

99:59:59.999 --> 99:59:59.999
It's important to note
that the <i>rebase</i> command

99:59:59.999 --> 99:59:59.999
is altering all of the commits
present in the branch.

99:59:59.999 --> 99:59:59.999
It's preserving all of the work you did,

99:59:59.999 --> 99:59:59.999
but their location and relationship
to other commits

99:59:59.999 --> 99:59:59.999
is all changing.

99:59:59.999 --> 99:59:59.999
This is primarily used for a branch
that <i>you only</i> own,

99:59:59.999 --> 99:59:59.999
and isn't being worked on by others.

99:59:59.999 --> 99:59:59.999
The change in the relationship,

99:59:59.999 --> 99:59:59.999
and identifier for each of those commits,

99:59:59.999 --> 99:59:59.999
makes it difficult to reconcile
with the work of others.

99:59:59.999 --> 99:59:59.999
We're primarily talking about a branch
that <i>you</i> are focused on.

99:59:59.999 --> 99:59:59.999
But with those constraints in place,
the use is quite simple.

99:59:59.999 --> 99:59:59.999
<i>git checkout</i> to the feature branch,

99:59:59.999 --> 99:59:59.999
<i>git rebase</i> on the source branch,
typically <i>master</i>.

99:59:59.999 --> 99:59:59.999
That will then iteratively walk through
all of the commits

99:59:59.999 --> 99:59:59.999
that have happened on the feature branch,

99:59:59.999 --> 99:59:59.999
and replay them as if they were being
robotically rewritten,

99:59:59.999 --> 99:59:59.999
starting from the latest point in time
on the master branch.

99:59:59.999 --> 99:59:59.999
When the process completes,

99:59:59.999 --> 99:59:59.999
after seeing it step through all of the individual commits,

99:59:59.999 --> 99:59:59.999
it will let you know that the <i>rebase</i> is complete,

99:59:59.999 --> 99:59:59.999
and you'll return to the command prompt

99:59:59.999 --> 99:59:59.999
and what appears to be a similar state

99:59:59.999 --> 99:59:59.999
to before you ran that instruction.

99:59:59.999 --> 99:59:59.999
However, all of those historical commits
now have new identifiers,

99:59:59.999 --> 99:59:59.999
keep that in mind.

99:59:59.999 --> 99:59:59.999
You'll find a request to use this pattern

99:59:59.999 --> 99:59:59.999
is most common in open source projects.

99:59:59.999 --> 99:59:59.999
It's because they want to optimize

99:59:59.999 --> 99:59:59.999
for future readership of the code base.

99:59:59.999 --> 99:59:59.999
A single straight line of history
provides the easiest reading

99:59:59.999 --> 99:59:59.999
for a future contributor to this project.

99:59:59.999 --> 99:59:59.999
This is why they put the burden
on the contributors,

99:59:59.999 --> 99:59:59.999
to make the history clean.

99:59:59.999 --> 99:59:59.999
It's an effort, but one that benefits

99:59:59.999 --> 99:59:59.999
every future collaborator on this project.

99:59:59.999 --> 99:59:59.999
Continuously delivered applications,

99:59:59.999 --> 99:59:59.999
such as web services, and web apps,