WEBVTT
00:00:00.286 --> 00:00:03.221
Git Rebase is the ability
to take existing commits,
00:00:03.221 --> 00:00:06.540
and to place them on a branch
that starts today.
00:00:06.726 --> 00:00:08.937
♪ (jazzy theme music throughout) ♪
00:00:12.355 --> 00:00:14.501
Creating a branch is a tough decision.
00:00:14.715 --> 00:00:17.133
Start it today, or start it later?
00:00:17.475 --> 00:00:20.618
Well, some important fixes
might be happening right now.
00:00:20.771 --> 00:00:22.881
So better wait until tomorrow.
00:00:23.026 --> 00:00:26.101
That difficult decision
has gone away with Git.
00:00:26.489 --> 00:00:28.140
Start a branch whenever you like,
00:00:28.161 --> 00:00:31.389
and make it contain the changes
that you intend to deliver.
00:00:31.507 --> 00:00:33.353
Focused on a particular feature,
00:00:33.750 --> 00:00:35.907
bug fix, or objective.
00:00:38.976 --> 00:00:40.699
What about wanting this to start
00:00:40.699 --> 00:00:42.383
at a later place in history,
00:00:42.383 --> 00:00:44.647
in order to incorporate those hot fixes
00:00:44.647 --> 00:00:46.432
that are going on
to the master branch?
00:00:46.860 --> 00:00:49.686
No problem.
Rebase to the rescue.
00:00:50.038 --> 00:00:52.775
Rebase, in its standard usage form,
00:00:52.775 --> 00:00:57.868
allows one branch to be relocated
farther down the history track,
00:00:58.362 --> 00:01:02.899
meaning taking all of the changes
that are isolated on your branch
00:01:03.124 --> 00:01:05.707
and acting as if they happened after
00:01:05.935 --> 00:01:08.362
all of the modern work
on the master branch.
00:01:09.019 --> 00:01:11.456
This accomplishes the same thing,
00:01:11.456 --> 00:01:14.580
but with cleaner history
than doing a reverse merge
00:01:14.580 --> 00:01:17.290
from the master branch
to the feature branch.
00:01:17.707 --> 00:01:20.485
The same contents will be present
in the feature branch,
00:01:20.720 --> 00:01:23.503
but without the complication of the merge
00:01:23.757 --> 00:01:26.969
going into that feature branch,
and recorded in its history.
00:01:29.876 --> 00:01:32.124
It's important to note
that the rebase command
00:01:32.274 --> 00:01:35.160
is altering all of the commits
present in the branch.
00:01:35.550 --> 00:01:37.801
It's preserving all of the work you did,
00:01:38.057 --> 00:01:41.201
but their location and relationship
to other commits
00:01:41.201 --> 00:01:42.583
is all changing.
00:01:43.075 --> 00:01:46.485
This is primarily used for a branch
that you only own,
00:01:46.485 --> 00:01:48.643
and isn't being worked on by others.
00:01:48.970 --> 00:01:50.243
The change in the relationship
00:01:50.243 --> 00:01:52.322
and identifier for each of those commits,
00:01:52.322 --> 00:01:55.380
makes it difficult to reconcile
with the work of others.
00:01:55.573 --> 00:02:00.041
We're primarily talking about a branch
that you are focused on.
00:02:00.492 --> 00:02:04.058
But with those constraints in place,
the use is quite simple.
00:02:04.471 --> 00:02:07.168
Git checkout to the feature branch,
00:02:07.647 --> 00:02:12.443
git rebase on the source branch,
typically master.
00:02:13.231 --> 00:02:15.402
That will then iteratively walk through
00:02:15.402 --> 00:02:17.983
all of the commits that have happened
on the feature branch,
00:02:17.983 --> 00:02:22.797
and replay them as if they were being
robotically rewritten,
00:02:23.098 --> 00:02:27.590
starting from the latest point in time
on the master branch.
00:02:27.889 --> 00:02:29.561
When the process completes,
00:02:29.766 --> 00:02:32.862
after seeing it step through
all of the individual commits,
00:02:33.390 --> 00:02:36.310
it will let you know that
the rebase is complete,
00:02:36.310 --> 00:02:37.898
and you'll return
to the command prompt
00:02:37.898 --> 00:02:40.174
in what appears to be a similar state
00:02:40.174 --> 00:02:42.330
to before you ran that instruction.
00:02:42.595 --> 00:02:47.146
However, all of those historical commits
now have new identifiers,
00:02:47.443 --> 00:02:48.595
keep that in mind.
00:02:48.714 --> 00:02:50.900
You'll find a request to use this pattern
00:02:50.900 --> 00:02:53.128
is most common in open source projects.
00:02:53.659 --> 00:02:55.936
It's because they want to optimize
00:02:55.936 --> 00:02:57.833
for future readership of the code base.
00:02:58.137 --> 00:03:01.899
A single straight line of history
provides the easiest reading
00:03:02.082 --> 00:03:04.503
for a future contributor to this project.
00:03:04.750 --> 00:03:06.933
This is why they put the burden
on the contributors,
00:03:06.933 --> 00:03:08.595
to make the history clean.
00:03:08.997 --> 00:03:11.154
It's an effort, but one that benefits
00:03:11.154 --> 00:03:14.176
every future collaborator
on this project.
00:03:16.803 --> 00:03:18.936
Continuously delivered applications,
00:03:18.936 --> 00:03:21.391
such as web services, and web apps,
00:03:21.915 --> 00:03:25.881
are optimized, generally,
for merges, not rebase.
00:03:26.447 --> 00:03:29.244
They want the quickest possible
delivery mechanism
00:03:29.478 --> 00:03:33.386
to send a change, small and focused,
into the master branch.
00:03:33.884 --> 00:03:36.087
If that doesn't do
everything that it should,
00:03:36.482 --> 00:03:39.857
another branch is worked on,
and merged back in again.
00:03:40.260 --> 00:03:41.897
Rebase is a powerful feature
00:03:41.897 --> 00:03:44.052
that lets you optimize
for clarity of history.
00:03:44.370 --> 00:03:47.228
Just bear in mind the needs
of your project and your team.
00:03:47.716 --> 00:03:50.321
If it is for quick delivery
of feature branches,
00:03:50.321 --> 00:03:51.641
just merge them in.
00:03:51.907 --> 00:03:54.996
If it's for clarity of history,
engage in using Rebase.
00:03:56.979 --> 00:03:58.978
Thanks for watching this
Git & GitHub Foundations
00:03:58.978 --> 00:04:00.429
episode on Rebase.
00:04:00.563 --> 00:04:02.592
Be sure to subscribe
to our channel, over here,
00:04:02.592 --> 00:04:05.365
ask us questions or comments
in the box below,
00:04:05.365 --> 00:04:08.695
or watch one of the related episodes,
such as on creating a branch.