9:59:59.000,9:59:59.000
<i>Git Rebase</i> is the ability[br]to take existing commits,

9:59:59.000,9:59:59.000
and to place them on a branch[br]that starts today.

9:59:59.000,9:59:59.000
♪ (jazzy theme music throughout) ♪

9:59:59.000,9:59:59.000
Creating a branch is a tough decision.

9:59:59.000,9:59:59.000
Start it today, or start it later?

9:59:59.000,9:59:59.000
Well, some important fixes[br]might be happening right now.

9:59:59.000,9:59:59.000
So better wait until tomorrow.

9:59:59.000,9:59:59.000
That difficult decision[br]has gone away with <i>Git</i>.

9:59:59.000,9:59:59.000
Start a branch whenever you like,

9:59:59.000,9:59:59.000
and make it contain the changes[br]that you intend to deliver.

9:59:59.000,9:59:59.000
Focused on a particular feature,

9:59:59.000,9:59:59.000
bug fix, or objective.

9:59:59.000,9:59:59.000
What about wanting this to start

9:59:59.000,9:59:59.000
at a later place in history,

9:59:59.000,9:59:59.000
in order to incorporate those hot fixes

9:59:59.000,9:59:59.000
that are going on to the master branch?

9:59:59.000,9:59:59.000
No problem.[br]<i>Rebase</i> to the rescue.

9:59:59.000,9:59:59.000
<i>Rebase</i>, in its standard usage form,

9:59:59.000,9:59:59.000
allows one branch to be relocated[br]farther down the history track,

9:59:59.000,9:59:59.000
meaning taking all of the changes[br]that are isolated on your branch,

9:59:59.000,9:59:59.000
and acting as if they happened <i>after</i>

9:59:59.000,9:59:59.000
all of the modern work[br]on the master branch.

9:59:59.000,9:59:59.000
This accomplishes the same thing,[br]but with cleaner history,

9:59:59.000,9:59:59.000
than doing a reverse merge

9:59:59.000,9:59:59.000
from the master branch[br]to the feature branch.

9:59:59.000,9:59:59.000
The same contents will be present[br]in the feature branch,

9:59:59.000,9:59:59.000
but without the complication of the merge,

9:59:59.000,9:59:59.000
going into that feature branch,[br]and recorded in its history.

9:59:59.000,9:59:59.000
It's important to note[br]that the <i>rebase</i> command

9:59:59.000,9:59:59.000
is altering all of the commits[br]present in the branch.

9:59:59.000,9:59:59.000
It's preserving all of the work you did,

9:59:59.000,9:59:59.000
but their location and relationship[br]to other commits

9:59:59.000,9:59:59.000
is all changing.

9:59:59.000,9:59:59.000
This is primarily used for a branch[br]that <i>you only</i> own,

9:59:59.000,9:59:59.000
and isn't being worked on by others.

9:59:59.000,9:59:59.000
The change in the relationship,

9:59:59.000,9:59:59.000
and identifier for each of those commits,

9:59:59.000,9:59:59.000
makes it difficult to reconcile[br]with the work of others.

9:59:59.000,9:59:59.000
We're primarily talking about a branch[br]that <i>you</i> are focused on.

9:59:59.000,9:59:59.000
But with those constraints in place,[br]the use is quite simple.

9:59:59.000,9:59:59.000
<i>git checkout</i> to the feature branch,

9:59:59.000,9:59:59.000
<i>git rebase</i> on the source branch,[br]typically <i>master</i>.

9:59:59.000,9:59:59.000
That will then iteratively walk through[br]all of the commits

9:59:59.000,9:59:59.000
that have happened on the feature branch,

9:59:59.000,9:59:59.000
and replay them as if they were being[br]robotically rewritten,

9:59:59.000,9:59:59.000
starting from the latest point in time[br]on the master branch.

9:59:59.000,9:59:59.000
When the process completes,

9:59:59.000,9:59:59.000
after seeing it step through[br]all of the individual commits,

9:59:59.000,9:59:59.000
it will let you know that[br]the <i>rebase</i> is complete,

9:59:59.000,9:59:59.000
and you'll return to the command prompt

9:59:59.000,9:59:59.000
and what appears to be a similar state

9:59:59.000,9:59:59.000
to before you ran that instruction.

9:59:59.000,9:59:59.000
However, all of those historical commits[br]now have new identifiers,

9:59:59.000,9:59:59.000
keep that in mind.

9:59:59.000,9:59:59.000
You'll find a request to use this pattern

9:59:59.000,9:59:59.000
is most common in open source projects.

9:59:59.000,9:59:59.000
It's because they want to optimize

9:59:59.000,9:59:59.000
for future readership of the code base.

9:59:59.000,9:59:59.000
A single straight line of history[br]provides the easiest reading

9:59:59.000,9:59:59.000
for a future contributor to this project.

9:59:59.000,9:59:59.000
This is why they put the burden[br]on the contributors,

9:59:59.000,9:59:59.000
to make the history clean.

9:59:59.000,9:59:59.000
It's an effort, but one that benefits

9:59:59.000,9:59:59.000
every future collaborator on this project.

9:59:59.000,9:59:59.000
Continuously delivered applications,

9:59:59.000,9:59:59.000
such as web services, and web apps,

9:59:59.000,9:59:59.000
are optimized, generally,[br]for merges, not <i>rebase</i>.

9:59:59.000,9:59:59.000
They want the quickest possible[br]delivery mechanism

9:59:59.000,9:59:59.000
to send a change, small and focused,[br]into the master branch.

9:59:59.000,9:59:59.000
If that doesn't do[br]everything that it should,

9:59:59.000,9:59:59.000
another branch is worked on,[br]and merged back in again.

9:59:59.000,9:59:59.000
<i>Rebase</i> is a powerful feature

9:59:59.000,9:59:59.000
that lets you optimize[br]for clarity of history.

9:59:59.000,9:59:59.000
Just bear in mind the needs[br]of your project and your team.

9:59:59.000,9:59:59.000
If it is for quick delivery[br]of feature branches,

9:59:59.000,9:59:59.000
just merge them in.

9:59:59.000,9:59:59.000
If it's for clarity of history,[br]engage in using <i>Rebase</i>.

9:59:59.000,9:59:59.000
Thanks for watching this[br]Git &amp; GitHub Foundations

9:59:59.000,9:59:59.000
episode on <i>Rebase</i>.

9:59:59.000,9:59:59.000
Be sure to subscribe[br]to our channel, over here,

9:59:59.000,9:59:59.000
ask us questions or comments[br]in the box below,

9:59:59.000,9:59:59.000
or watch one of the related episodes,[br]such as on creating a branch.