Rebase • GitHub & Git Foundations

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

and 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.