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.