Git Rebase is the ability
to take existing commits,
and to place them on a branch
that starts today.
♪ (jazzy theme music throughout) ♪
Creating a branch is a tough decision.
Start it today, or start it later?
Well, some important fixes
might be happening right now.
So better wait until tomorrow.
That difficult decision
has gone away with Git.
Start a branch whenever you like,
and make it contain the changes
that you intend to deliver.
Focused on a particular feature,
bug fix, or objective.
What about wanting this to start
at a later place in history,
in order to incorporate those hot fixes
that are going on
to the master branch?
No problem.
Rebase to the rescue.
Rebase, in its standard usage form,
allows one branch to be relocated
farther down the history track,
meaning taking all of the changes
that are isolated on your branch
and acting as if they happened after
all of the modern work
on the master branch.
This accomplishes the same thing,
but with cleaner history
than doing a reverse merge
from the master branch
to the feature branch.
The same contents will be present
in the feature branch,
but without the complication of the merge
going into that feature branch,
and recorded in its history.
It's important to note
that the rebase command
is altering all of the commits
present in the branch.
It's preserving all of the work you did,
but their location and relationship
to other commits
is all changing.
This is primarily used for a branch
that you only own,
and isn't being worked on by others.
The change in the relationship
and identifier for each of those commits,
makes it difficult to reconcile
with the work of others.
We're primarily talking about a branch
that you are focused on.
But with those constraints in place,
the use is quite simple.
Git checkout to the feature branch,
git rebase on the source branch,
typically master.
That will then iteratively walk through
all of the commits that have happened
on the feature branch,
and replay them as if they were being
robotically rewritten,
starting from the latest point in time
on the master branch.
When the process completes,
after seeing it step through
all of the individual commits,
it will let you know that
the rebase is complete,
and you'll return
to the command prompt
in what appears to be a similar state
to before you ran that instruction.
However, all of those historical commits
now have new identifiers,
keep that in mind.
You'll find a request to use this pattern
is most common in open source projects.
It's because they want to optimize
for future readership of the code base.
A single straight line of history
provides the easiest reading
for a future contributor to this project.
This is why they put the burden
on the contributors,
to make the history clean.
It's an effort, but one that benefits
every future collaborator
on this project.
Continuously delivered applications,
such as web services, and web apps,
are optimized, generally,
for merges, not rebase.
They want the quickest possible
delivery mechanism
to send a change, small and focused,
into the master branch.
If that doesn't do
everything that it should,
another branch is worked on,
and merged back in again.
Rebase is a powerful feature
that lets you optimize
for clarity of history.
Just bear in mind the needs
of your project and your team.
If it is for quick delivery
of feature branches,
just merge them in.
If it's for clarity of history,
engage in using Rebase.
Thanks for watching this
Git & GitHub Foundations
episode on Rebase.
Be sure to subscribe
to our channel, over here,
ask us questions or comments
in the box below,
or watch one of the related episodes,
such as on creating a branch.