0:00:00.286,0:00:03.221
<i>Git Rebase</i> is the ability[br]to take existing commits,

0:00:03.221,0:00:06.540
and to place them on a branch[br]that starts today.

0:00:06.726,0:00:08.937
♪ (jazzy theme music throughout) ♪

0:00:12.355,0:00:14.501
Creating a branch is a tough decision.

0:00:14.715,0:00:17.133
Start it today, or start it later?

0:00:17.475,0:00:20.618
Well, some important fixes[br]might be happening right now.

0:00:20.771,0:00:22.881
So better wait until tomorrow.

0:00:23.026,0:00:26.101
That difficult decision[br]has gone away with <i>Git</i>.

0:00:26.489,0:00:28.140
Start a branch whenever you like,

0:00:28.161,0:00:31.389
and make it contain the changes[br]that you intend to deliver.

0:00:31.507,0:00:33.353
Focused on a particular feature,

0:00:33.750,0:00:35.907
bug fix, or objective.

0:00:38.976,0:00:40.699
What about wanting this to start

0:00:40.699,0:00:42.383
at a later place in history,

0:00:42.383,0:00:44.647
in order to incorporate those hot fixes

0:00:44.647,0:00:46.432
that are going on[br]to the master branch?

0:00:46.860,0:00:49.686
No problem.[br]<i>Rebase</i> to the rescue.

0:00:50.038,0:00:52.775
<i>Rebase</i>, in its standard usage form,

0:00:52.775,0:00:57.868
allows one branch to be relocated[br]farther down the history track,

0:00:58.362,0:01:02.899
meaning taking all of the changes[br]that are isolated on your branch

0:01:03.124,0:01:05.707
and acting as if they happened <i>after</i>

0:01:05.935,0:01:08.362
all of the modern work[br]on the master branch.

0:01:09.019,0:01:11.456
This accomplishes the same thing,

0:01:11.456,0:01:14.580
but with cleaner history[br]than doing a reverse merge

0:01:14.580,0:01:17.290
from the master branch[br]to the feature branch.

0:01:17.707,0:01:20.485
The same contents will be present[br]in the feature branch,

0:01:20.720,0:01:23.503
but without the complication of the merge

0:01:23.757,0:01:26.969
going into that feature branch,[br]and recorded in its history.

0:01:29.876,0:01:32.124
It's important to note[br]that the <i>rebase</i> command

0:01:32.274,0:01:35.160
is altering all of the commits[br]present in the branch.

0:01:35.550,0:01:37.801
It's preserving all of the work you did,

0:01:38.057,0:01:41.201
but their location and relationship[br]to other commits

0:01:41.201,0:01:42.583
is all changing.

0:01:43.075,0:01:46.485
This is primarily used for a branch[br]that <i>you only</i> own,

0:01:46.485,0:01:48.643
and isn't being worked on by others.

0:01:48.970,0:01:50.243
The change in the relationship

0:01:50.243,0:01:52.322
and identifier for each of those commits,

0:01:52.322,0:01:55.380
makes it difficult to reconcile[br]with the work of others.

0:01:55.573,0:02:00.041
We're primarily talking about a branch[br]that <i>you</i> are focused on.

0:02:00.492,0:02:04.058
But with those constraints in place,[br]the use is quite simple.

0:02:04.471,0:02:07.168
<i>Git checkout</i> to the feature branch,

0:02:07.647,0:02:12.443
<i>git rebase</i> on the source branch,[br]typically <i>master</i>.

0:02:13.231,0:02:15.402
That will then iteratively walk through

0:02:15.402,0:02:17.983
all of the commits that have happened[br]on the feature branch,

0:02:17.983,0:02:22.797
and replay them as if they were being[br]robotically rewritten,

0:02:23.098,0:02:27.590
starting from the latest point in time[br]on the master branch.

0:02:27.889,0:02:29.561
When the process completes,

0:02:29.766,0:02:32.862
after seeing it step through[br]all of the individual commits,

0:02:33.390,0:02:36.310
it will let you know that[br]the <i>rebase</i> is complete,

0:02:36.310,0:02:37.898
and you'll return[br]to the command prompt

0:02:37.898,0:02:40.174
in what appears to be a similar state

0:02:40.174,0:02:42.330
to before you ran that instruction.

0:02:42.595,0:02:47.146
However, all of those historical commits[br]now have new identifiers,

0:02:47.443,0:02:48.595
keep that in mind.

0:02:48.714,0:02:50.900
You'll find a request to use this pattern

0:02:50.900,0:02:53.128
is most common in open source projects.

0:02:53.659,0:02:55.936
It's because they want to optimize

0:02:55.936,0:02:57.833
for future readership of the code base.

0:02:58.137,0:03:01.899
A single straight line of history[br]provides the easiest reading

0:03:02.082,0:03:04.503
for a future contributor to this project.

0:03:04.750,0:03:06.933
This is why they put the burden[br]on the contributors,

0:03:06.933,0:03:08.595
to make the history clean.

0:03:08.997,0:03:11.154
It's an effort, but one that benefits

0:03:11.154,0:03:14.176
<i>every</i> future collaborator[br]on this project.

0:03:16.803,0:03:18.936
Continuously delivered applications,

0:03:18.936,0:03:21.391
such as web services, and web apps,

0:03:21.915,0:03:25.881
are optimized, generally,[br]for merges, not <i>rebase</i>.

0:03:26.447,0:03:29.244
They want the quickest possible[br]delivery mechanism

0:03:29.478,0:03:33.386
to send a change, small and focused,[br]into the master branch.

0:03:33.884,0:03:36.087
If that doesn't do[br]everything that it should,

0:03:36.482,0:03:39.857
another branch is worked on,[br]and merged back in again.

0:03:40.260,0:03:41.897
<i>Rebase</i> is a powerful feature

0:03:41.897,0:03:44.052
that lets you optimize[br]for clarity of history.

0:03:44.370,0:03:47.228
Just bear in mind the needs[br]of your project and your team.

0:03:47.716,0:03:50.321
If it is for quick delivery[br]of feature branches,

0:03:50.321,0:03:51.641
just merge them in.

0:03:51.907,0:03:54.996
If it's for clarity of history,[br]engage in using <i>Rebase</i>.

0:03:56.979,0:03:58.978
Thanks for watching this[br]Git &amp; GitHub Foundations

0:03:58.978,0:04:00.429
episode on <i>Rebase</i>.

0:04:00.563,0:04:02.592
Be sure to subscribe[br]to our channel, over here,

0:04:02.592,0:04:05.365
ask us questions or comments[br]in the box below,

0:04:05.365,0:04:08.695
or watch one of the related episodes,[br]such as on creating a branch.