The 2016 Git Retrospective: Rebase
Rebasing is a convenient and powerful way to restructure your Git history. You can now rebase and pull with a single command, or perform a rebase exec without needing to drop into interactive mode.
Join the DZone community and get the full member experience.
Join For Free
welcome to the fourth part of our git in 2016 retrospective series! in
part three
, we covered changes made to git and
git lfs
to improve support for tracking large files with git repositories. this time, we'll be looking at some enhancements made to the
git rebase
command throughout the year.
in march, git v2.8 added the ability to interactively rebase whilst pulling with a
git pull --rebase=interactive
. conversely, june's git v2.9 release implemented support for performing a rebase exec without needing to drop into interactive mode via
git rebase -x
.
re -wah?
before we dive in, i suspect there may be a few readers who aren't totally familiar or comfortable with the rebase command or interactive rebasing. conceptually, it's pretty simple, but as with many of git's powerful features, the rebase is steeped in some complex-sounding terminology. so, before we dive in, let's quickly review what a rebase is.
rebasing means rewriting one or more commits on a particular branch. the
git rebase
command is heavily overloaded, but the name rebase originates from the fact that it is often used to change a branch's base commit (the commit that you created the branch from).
conceptually, rebase unwinds the commits on your branch by temporarily storing them as a series of patches, and then reapplying them in order on top of the target commit.
rebasing a feature branch on master (
git rebase master
) is a great way to "freshen" your feature branch with the latest changes from master. for long-lived feature branches, regular rebasing minimizes the chance and severity of conflicts down the road.
some teams also choose to rebase immediately before merging their changes onto master in order to achieve a
fast-forward merge (
git merge --ff <feature>
). fast-forwarding merges your commits onto master by simply making the master ref point at the tip of your rewritten branch without creating a merge commit:
rebasing is so convenient and powerful that it has been baked into some other common git commands, such as
git pull
. if you have some unpushed changes on your local master branch, running
git pull
to pull your teammates' changes from the origin
will create an unnecessary merge commit:
this is kind of messy, and on busy teams, you'll get heapsof these unnecessary merge commits.
git pull --rebase
rebases your local changes on top of your teammates' without creating a merge commit:
this is pretty neat! git v2.8 also introduced an even cooler feature that lets you rebase interactivelywhilst pulling.
interactive rebasing
interactive rebasing is a more powerful form of rebasing. it also rewrites commits but gives you a chance to modify them as they are reapplied onto the new base.
when you run
git rebase --interactive
(or
git pull --rebase=interactive
), you'll be presented with a list of commits in your text editor of choice:
$ git rebase master --interactive
pick 2fde787 ace-1294: replaced miniamalcommit with string in test
pick ed93626 ace-1294: removed pull request service from test
pick b02eb9a ace-1294: moved fromhash, tohash and difftype to batch
pick e68f710 ace-1294: added testing data to batch email file
# rebase f32fa9d..0ddde5f onto f32fa9d (4 commands)
#
# commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# these lines can be re-ordered; they are executed from top to bottom.
#
# if you remove a line here that commit will be lost.
notice that each commit has the word
pick
next to it. that's rebase-speak for, "keep this commit as-is." if you quit your text editor now, it will perform a normal rebase as described in the last section. however, if you change
pick
to
edit
or one of the other rebase commands,
rebase will let you mutate the commit before it is reapplied! there are several available rebase commands:
-
reword: edit the commit message. -
edit: e dit the files that were committed. -
squash: combine the commit with the previous commit (the one above it in the file), concatenating the commit messages. -
fixup: combine the commit with the commit above it, and uses the previous commit's log message verbatim (this is handy if you created a second commit for a small change that should have been in the original commit, i.e., you forgot to stage a file). -
exec: run an arbitrary shell command (we'll look at a neat use-case for this later, in the next section). -
drop: this kills the commit.
you can also reorder commits within the file, which changes the order in which they're reapplied. this is handy if you have interleaved commits that are addressing different topics and you want to use
squash
or
fixup
to combine them into logically atomic commits.
once you've set up the commands and saved the file, git will iterate through each commit, pausing at each
reword
and
edit
for you to make your desired changes and automatically applying any
squash
,
fixup
,
exec
, and
drop
commands for you.
non-interactive exec
when you rebase, you’re essentially rewriting history by applying each of your new commits on top of the specified base.
git pull --rebase
can be a little risky because
depending on the nature of the changes from the upstream branch, you may encounter test failures or even compilation problems for certain commits in your newly created history. if these changes cause merge conflicts, the rebase process will pause and allow you to resolve them. however, changes that merge cleanly may still break compilation or tests, leaving broken commits littering your history.
however, you can instruct git to run your project’s test suite for each rewritten commit. prior to git v2.9, you could do this with a combination of
git rebase −−interactive
and the
exec
command. for example, this:
$ git rebase master −−interactive −−exec=”npm test”
...would generate an interactive rebase plan that invokes
npm test
after rewriting each commit, ensuring that your tests still pass:
pick 2fde787 ace-1294: replaced miniamalcommit with string in test
exec npm test
pick ed93626 ace-1294: removed pull request service from test
exec npm test
pick b02eb9a ace-1294: moved fromhash, tohash and difftype to batch
exec npm test
pick e68f710 ace-1294: added testing data to batch email file
exec npm test
# rebase f32fa9d..0ddde5f onto f32fa9d (4 command(s))in the event that a test fails, rebase will pause to let you fix the tests (and apply your changes to that commit):
291 passing
1 failing
1) host request “after all” hook:
uncaught error: connect econnreset 127.0.0.1:3001
…
npm err! test failed.
execution failed: npm test
you can fix the problem, and then run
git rebase −−continuethis is handy, but needing to do an interactive rebase is a bit clunky. as of git v2.9, you can perform a non-interactive rebase exec, with:
$ git rebase master -x “npm test”
just replace
npm test
with
make
,
rake
,
mvn clean install
, or whatever you use to build and test your project.
a word of warning
just like in the movies, rewriting history is risky business. any commit that is rewritten as part of a rebase will have it's sha-1 id changed, which means that git will treat it as a totally different commit. if rewritten history is mixed with the original history, you'll get duplicate commits, which can cause a lot of confusion for your team.
to avoid this problem, you only need to follow one simple rule: never rebase a commit that you've already pushed!
stick to that and you'll be fine.
more to come!
we've only touched on a couple of user-facing features of
git rebase
. a heck of a lot of refactoring work also landed in 2016 that improved rebase performance and the robustness of interactive rebase's parsing and sequencing. this work will continue into 2017 and yield further improvements to one of git's most unique and powerful commands. if you'd like to learn more about rebasing, check out atlassian's great tutorial on
rewriting git history
. then keep an eye out for the next article in our retrospective series, which will cover a powerful feature with a slightly checkered past: git submodules.
as always, if you've got some git tips to share, come say hi on twitter — i'm @kannonboy .
if you stumbled on these articles out of order, you can check out the other topics covered in our git in 2016 retrospective below:
or, if you've read 'em all and still want more, check out atlassian's git tutorials (i'm a regular contributor there) for some tips and tricks to improve your workflow.
Opinions expressed by DZone contributors are their own.
Comments