How to abort rebase

Woman on Rails

Premature optimization is the root of all evil.

Git Rebase

When you are starting your adventure with git, it’s hard to know everything from the beginning. This is normal that you do small steps and discover new features on the way. Today, I have a very nice git feature for you. It will allow you to have a better structure and order of your commits. This is very useful especially when you work in a team. I will show you how to use git rebase. This is the third article in the git series, so if you want to know more about basics of git usage, go to my previous articles.

Git merge

Normally, when you start working with branches, you will just use git merge command. This will allow you to combine your changes with the main branch. It’s OK. You achieve what you want to. Your branch is merged with the main branch. But, what you could notice too, is that the changes are in a very strange order. They aren’t grouped by context. They are grouped by date. In some cases it’s a good solution, but not here.

Imagine that you need to implement login functionality. You create pure HTML as one commit. In the second commit, you add communication with the backend. Everything is working, so you decide to merge those changes with the master branch. In the meantime, your team did other tasks. After combining all changes, one of your commits is on top of the git tree and one somewhere in a middle. It’s very hard to reproduce the way of thinking or the implementation steps for a specific feature. In this case, git tree can look like this:

You can see that even you have some connected commits, after the merge, it looks like one big mess. The other thing is that you can see commits with the title “Merged in…”. These commits are automatically generated during the merging process.

Git rebase

Here, you see everything in order. Connected commits are in one group. You also have a history of our branches.

Now it’s time to go deeper. Let’s compare git merge and git rebase with more details.

Git merge vs git rebase

When you use git merge, git will try to resolve conflicts at once. It will put all changes together in date-time order. In case there will be some conflicts, you will see them as one list. After you resolve them and commit, the merge commit will be generated. But when you use rebase, git moves your local changes to a temporary area and pull all changes from the remote repository to your branch. Then one by one it will move each of your local changes on top of the downloaded changes. We often say that rebase moves your local changes on top of the HEAD.

What is HEAD?

HEAD is a reference to the last change in the current branch. You can think about it as a marker, which tells you where you are now. If on the remote repository are changes, that you don’t have them locally, you can say that you are behind the remote HEAD. So, when you pull all changes from the remote repository, you can say that you are on top of the HEAD. It is possible to move this HEAD marker to a specific commit. In this case, you will say that your HEAD is in detached state. This means that it isn’t referring to a named branch, but only to some specific commit. This is illustrated below:

How to use git rebase?

How to abort rebase

Check your version of git by running

SYNOPSIS

DESCRIPTION

If
is specified, git rebase will perform an automatic git switch
before doing anything else. Otherwise it remains on the current branch.

The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD.. are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).

Assume the following history exists and the current branch is «topic»:

From this point, the result of either of the following commands:

If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped and warnings will be issued (if the merge backend is used). For example, running git rebase master on the following history (in which A’ and A introduce the same set of changes, but have different committer information):

First let’s assume your topic is based on branch next. For example, a feature developed in topic depends on some functionality which is found in next.

We want to make topic forked from branch master; for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:

We can get this using the following command:

then the command

would result in:

This is useful when topicB does not depend on topicA.

A range of commits could also be removed with rebase. If we have the following situation:

then the command

would result in the removal of commits F and G:

As a special case, you may use «A. B» as a shortcut for the merge base of A and B if there is exactly one merge base. You can leave out at most one of A and B, in which case it defaults to HEAD.

This option is useful in the case where one is developing a feature on top of an upstream branch. While the feature is being worked on, the upstream branch may advance and it may not be the best idea to keep rebasing on top of the upstream but to keep the base commit as-is.

See also INCOMPATIBLE OPTIONS below.

Upstream branch to compare against. May be any valid commit, not just an existing branch name. Defaults to the configured upstream for the current branch.

Restart the rebasing process after having resolved a merge conflict.

Abort the rebase operation and reset HEAD to the original branch. If
was provided when the rebase operation was started, then HEAD will be reset to
. Otherwise HEAD will be reset to where it was when the rebase operation was started.

Use applying strategies to rebase (calling git-am internally). This option may become a no-op in the future once the merge backend handles everything the apply one does.

See also INCOMPATIBLE OPTIONS below.

See also INCOMPATIBLE OPTIONS below.

Usage of this flag will probably be rare, since you can get rid of commits that start empty by just firing up an interactive rebase and removing the lines corresponding to the commits you don’t want. This flag exists as a convenient shortcut, such as for cases where external tools generate many empty commits and you want them all removed.

See also INCOMPATIBLE OPTIONS below.

—reapply-cherry-picks allows rebase to forgo reading all upstream commits, potentially improving performance.

See also INCOMPATIBLE OPTIONS below.

No-op. Rebasing commits with an empty message used to fail and this option would override that behavior, allowing commits with empty messages to be rebased. Now commits with an empty message do not cause rebasing to halt.

See also INCOMPATIBLE OPTIONS below.

Restart the rebasing process by skipping the current patch.

Edit the todo list during an interactive rebase.

Using merging strategies to rebase (default).

See also INCOMPATIBLE OPTIONS below.

Because git rebase replays each commit from the working branch on top of the branch using the given strategy, using the ours strategy simply empties all patches from the
, which makes little sense.

See also INCOMPATIBLE OPTIONS below.

See also INCOMPATIBLE OPTIONS below.

Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible.

Show a diffstat of what changed upstream since the last rebase. The diffstat is also controlled by the configuration option rebase.stat.

Do not show a diffstat as part of the rebase process.

This option bypasses the pre-rebase hook. See also githooks[5].

See also INCOMPATIBLE OPTIONS below.

Individually replay all rebased commits instead of fast-forwarding over the unchanged ones. This ensures that the entire history of the rebased branch is composed of new commits.

You may find this helpful after reverting a topic branch merge, as this option recreates the topic branch with fresh commits so it can be remerged successfully without needing to «revert the reversion» (see the revert-a-faulty-merge How-To for details).

Use reflog to find a better common ancestor between and
when calculating which commits have been introduced by
.

See also INCOMPATIBLE OPTIONS below.

Ignore whitespace differences when trying to reconcile differences. Currently, each backend implements an approximation of this behavior:

When applying a patch, ignore changes in whitespace in context lines. Unfortunately, this means that if the «old» lines being replaced by the patch differ only in whitespace from the existing file, you will get a merge conflict instead of a successful patch application.

Treat lines with only whitespace changes as unchanged when merging. Unfortunately, this means that any patch hunks that were intended to modify whitespace and nothing else will be dropped, even if the other side had no changes that conflicted.

See also INCOMPATIBLE OPTIONS below.

See also INCOMPATIBLE OPTIONS below.

See also INCOMPATIBLE OPTIONS below.

Make a list of the commits which are about to be rebased. Let the user edit that list before rebasing. This mode can also be used to split commits (see SPLITTING COMMITS below).

The commit list format can be changed by setting the configuration option rebase.instructionFormat. A customized instruction format will automatically have the long commit hash prepended to the format.

See also INCOMPATIBLE OPTIONS below.

See also REBASING MERGES and INCOMPATIBLE OPTIONS below.

Append «exec » after each line creating a commit in the final history. will be interpreted as one or more shell commands. Any command that fails will interrupt the rebase, with exit code 1.

See also INCOMPATIBLE OPTIONS below.

See also INCOMPATIBLE OPTIONS below.

See also INCOMPATIBLE OPTIONS below.

Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run rebase on a dirty worktree. However, use with care: the final stash application after a successful rebase might result in non-trivial conflicts.

INCOMPATIBLE OPTIONS

The following options:

are incompatible with the following options:

In addition, the following pairs of options are incompatible:

BEHAVIORAL DIFFERENCES

git rebase has two primary backends: apply and merge. (The apply backend used to be known as the am backend, but the name led to confusion as it looks like a verb instead of a noun. Also, the merge backend used to be known as the interactive backend, but it is now used for non-interactive cases as well. Both were renamed based on lower-level functionality that underpinned each.) There are some subtle differences in how these two backends behave:

Empty commits

The apply backend unfortunately drops intentionally empty commits, i.e. commits that started empty, though these are rare in practice. It also drops commits that become empty and has no option for controlling this behavior.

Directory rename detection

Due to the lack of accurate tree information (arising from constructing fake ancestors with the limited information available in patches), directory rename detection is disabled in the apply backend. Disabled directory rename detection means that if one side of history renames a directory and the other adds new files to the old directory, then the new files will be left behind in the old directory without any warning at the time of rebasing that you may want to move these files into the new directory.

Directory rename detection works with the merge backend to provide you warnings in such cases.

Context

The apply backend works by creating a sequence of patches (by calling format-patch internally), and then applying the patches in sequence (calling am internally). Patches are composed of multiple hunks, each with line numbers, a context region, and the actual changes. The line numbers have to be taken with some fuzz, since the other side will likely have inserted or deleted lines earlier in the file. The context region is meant to help find how to adjust the line numbers in order to apply the changes to the right lines. However, if multiple areas of the code have the same surrounding lines of context, the wrong one can be picked. There are real-world cases where this has caused commits to be reapplied incorrectly with no conflicts reported. Setting diff.context to a larger value may prevent such types of problems, but increases the chance of spurious conflicts (since it will require more lines of matching context to apply).

The merge backend works with a full copy of each relevant file, insulating it from these types of problems.

Labelling of conflicts markers

The merge backend works with the full commits on both sides of history and thus has no such limitations.

Hooks

The apply backend has not traditionally called the post-commit hook, while the merge backend has. Both have called the post-checkout hook, though the merge backend has squelched its output. Further, both backends only call the post-checkout hook with the starting point commit of the rebase, not the intermediate commits nor the final commit. In each case, the calling of these hooks was by accident of implementation rather than by design (both backends were originally implemented as shell scripts and happened to invoke other commands like git checkout or git commit that would call the hooks). Both backends should have the same behavior, though it is not entirely clear which, if any, is correct. We will likely make rebase stop calling either of these hooks in the future.

Interruptability

Commit Rewording

Miscellaneous differences

There are a few more behavioral differences that most folks would probably consider inconsequential but which are mentioned for completeness:

Reflog: The two backends will use different wording when describing the changes made in the reflog, though both will make use of the word «rebase».

Progress, informational, and error messages: The two backends provide slightly different progress and informational messages. Also, the apply backend writes error messages (such as «Your files would be overwritten…​») to stdout, while the merge backend writes them to stderr.

MERGE STRATEGIES

The ort strategy can take the following options:

This option forces conflicting hunks to be auto-resolved cleanly by favoring our version. Changes from the other tree that do not conflict with our side are reflected in the merge result. For a binary file, the entire contents are taken from our side.

This should not be confused with the ours merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring our history contains all that happened in it.

This is the opposite of ours; note that, unlike ours, there is no theirs merge strategy to confuse this merge option with.

ignore-space-change ignore-all-space ignore-space-at-eol ignore-cr-at-eol

If their version only introduces whitespace changes to a line, our version is used;

If our version introduces whitespace changes but their version includes a substantial change, their version is used;

Otherwise, the merge proceeds in the usual way.

This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See «Merging branches with differing checkin/checkout attributes» in gitattributes[5] for details.

Disables the renormalize option. This overrides the merge.renormalize configuration variable.

This option is a more advanced form of subtree strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match.

This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. It does not make use of detected copies. This was the default strategy for resolving two heads from Git v0.99.9k until v2.33.0.

The recursive strategy takes the same options as ort. However, there are three additional options that ort ignores (not documented above) that are potentially useful with the recursive strategy:

This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities. It does not handle renames.

This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch.

This is a modified ort strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree.

With the strategies that use 3-way merge (including the default, ort), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead.

NOTES

You should understand the implications of using git rebase on a repository that you share. See also RECOVERING FROM UPSTREAM REBASE below.

When the rebase is run, it will first execute a pre-rebase hook if one exists. You can use this hook to do sanity checks and reject the rebase if it isn’t appropriate. Please see the template pre-rebase hook script for an example.

Upon completion,
will be the current branch.

INTERACTIVE MODE

Rebasing interactively means that you have a chance to edit the commits which are rebased. You can reorder the commits, and you can remove them (weeding out bad or otherwise unwanted patches).

The interactive mode is meant for this type of workflow:

have a wonderful idea

hack on the code

prepare a series for submission

where point 2. consists of several instances of

finish something worthy of a commit

b) independent fixup

realize that something does not work

Sometimes the thing fixed in b.2. cannot be amended to the not-quite perfect commit it fixes, because that commit is buried deeply in a patch series. That is exactly what interactive rebase is for: use it after plenty of «a»s and «b»s, by rearranging and editing commits, and squashing multiple commits into one.

Start it with the last commit you want to retain as-is:

An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit. You can reorder the commits in this list to your heart’s content, and you can remove them. The list looks more or less like this:

The oneline descriptions are purely for your pleasure; git rebase will not look at them but at the commit names («deadbee» and «fa1afe1» in this example), so do not delete or edit the names.

By replacing the command «pick» with the command «edit», you can tell git rebase to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.

To interrupt the rebase (just like an «edit» command would do, but without cherry-picking any commit first), use the «break» command.

If you just want to edit the commit message for a commit, replace the command «pick» with the command «reword».

To drop a commit, replace the command «pick» with «drop», or just delete the matching line.

For example, if you want to reorder the last 5 commits, such that what was HEAD

And move the first patch to the end of the list.

You might want to recreate merge commits, e.g. if you have a history like this:

Suppose you want to rebase the side branch starting at «A» to «Q». Make sure that the current HEAD is «B», and call

Reordering and editing commits usually creates untested intermediate steps. You may want to check that your history editing did not break anything by running a test, or at least recompiling at intermediate points in history by using the «exec» command (shortcut «x»). You may do so by creating a todo list like this one:

This command lets you check that intermediate commits are compilable. The todo list becomes like that:

SPLITTING COMMITS

In interactive mode, you can mark commits with the action «edit». However, this does not necessarily mean that git rebase expects the result of this edit to be exactly one commit. Indeed, you can undo the commit, or you can add other commits. This can be used to split a commit into two:

Mark the commit you want to split with the action «edit».

Now add the changes to the index that you want to have in the first commit. You can use git add (possibly interactively) or git gui (or both) to do that.

Commit the now-current index with whatever commit message is appropriate now.

Repeat the last two steps until your working tree is clean.

If you are not absolutely sure that the intermediate revisions are consistent (they compile, pass the testsuite, etc.) you should use git stash to stash away the not-yet-committed changes after each commit, test, and amend the commit if fixes are necessary.

RECOVERING FROM UPSTREAM REBASE

Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.

To illustrate, suppose you are in a situation where someone develops a subsystem branch, and you are working on a topic that is dependent on this subsystem. You might end up with a history like the following:

If subsystem is rebased against master, the following happens:

If you now continue development as usual, and eventually merge topic to subsystem, the commits from subsystem will remain duplicated forever:

Such duplicates are generally frowned upon because they clutter up history, making it harder to follow. To clean things up, you need to transplant the commits on topic to the new subsystem tip, i.e., rebase topic. This becomes a ripple effect: anyone downstream from topic is forced to rebase too, and so on!

There are two kinds of fixes, discussed in the following subsections:

This happens if the subsystem rebase was a simple rebase and had no conflicts.

Hard case: The changes are not the same.

The easy case

Only works if the changes (patch IDs based on the diff contents) on subsystem are literally the same before and after the rebase subsystem did.

you will end up with the fixed history

The hard case

Things get more complicated if the subsystem changes do not exactly correspond to the ones before the rebase.

The idea is to manually tell git rebase «where the old subsystem ended and your topic began», that is, what the old merge base between them was. You will have to find a way to name the last commit of the old subsystem, for example:

Relative to the tip of topic: knowing that your topic has three commits, the old tip of subsystem must be topic

You can then transplant the old subsystem..topic to the new tip by saying (for the reflog case, and assuming you are on topic already):

The ripple effect of a «hard case» recovery is especially bad: everyone downstream from topic will now have to perform a «hard case» recovery too!

REBASING MERGES

The interactive rebase command was originally designed to handle individual patch series. As such, it makes sense to exclude merge commits from the todo list, as the developer may have merged the then-current master while working on the branch, only to rebase all the commits onto master eventually (skipping the merge commits).

However, there are legitimate reasons why a developer may want to recreate merge commits: to keep the branch structure (or «commit topology») when working on multiple, inter-related branches.

The label command associates a label with the current HEAD when that command is executed. These labels are created as worktree-local refs ( refs/rewritten/ ) that will be deleted when the rebase finishes. That way, rebase operations in multiple worktrees linked to the same repository do not interfere with one another. If the label command fails, it is rescheduled immediately, with a helpful message how to proceed.

If a merge command fails for any reason other than merge conflicts (i.e. when the merge operation did not even start), it is rescheduled immediately.

The one commit in this list that is not related to CMake may very well have been motivated by working on fixing all those bugs introduced by switching to CMake, but it addresses a different concern. To split this branch into two topic branches, the todo list could be edited like this:

CONFIGURATION

Default backend to use for rebasing. Possible choices are apply or merge. In the future, if the merge backend gains all remaining capabilities of the apply backend, this setting may become unused.

Whether to show a diffstat of what changed upstream since the last rebase. False by default.

A format string, as specified in git-log[1], to be used for the todo list during an interactive rebase. The format will automatically have the long commit hash prepended to the format.

If set to true, git rebase will use abbreviated command names in the todo list resulting in something like this:

Undoing a git rebase

How do I easily undo a git rebase? A lengthy manual method is:

In my current situation, this works because I can easily spot commits from both branches (one was my stuff, the other was my colleague’s stuff). However, my approach strikes me as suboptimal and error-prone (let’s say I had just rebased with two of my own branches).

Clarification: I am talking about a rebase during which multiple commits were replayed, not only one.

19 Answers 19

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

The easiest way would be to find the head commit of the branch as it was immediately before the rebase started in the reflog.

Suppose the old commit was HEAD@ <2>in the ref log:

In Windows, you may need to quote the reference:

You can check the history of the candidate old head by just doing a git log HEAD@ <2>(Windows: git log «HEAD@<2>» ).

If you’ve not disabled per branch reflogs you should be able to simply do git reflog branchname@ <1>as a rebase detaches the branch head before reattaching to the final head. I would double check this, though as I haven’t verified this recently.

Per default, all reflogs are activated for non-bare repositories:

Actually, rebase saves your starting point to ORIG_HEAD so this is usually as simple as:

Charles’s answer works, but you may want to do this:

Otherwise, you may get the message “ Interactive rebase already started ”.

Git Rebase HOWTO

Rebases can be scary! They are all about rewriting your commit history. But it is a useful tool when working on your own branch in order to keep your branch clean and tidy.

What is a rebase doing?

Conceptually, a rebase is taking a branch and replaying the commits from that branch one-by-one onto the new ‘base’ set of commits. A visual demonstration:

The old commits are still there! The rebase merely creates new commits and updates the branch to point to the new ones. However, the old commits will disappear once git runs garbage collection unless there is another branch that still contains those commits.

There is also an excellent interactive demo of git that will give you a visual understanding of how the working tree gets updated after various commands (rebase, merge, cherry-pick).

Simple rebase onto master

This is the most common operation you will see:

This will pull down the latest information from origin, and then it will take your branch and base it on the current version of master. This way your branch doesn’t need a dozen new ‘merge from master’ commits every time you’d like the newest updates to master in your current branch.

Dealing with conflicts

Sometimes your rebase runs will run into conflicts!

This is the error message you get:

From here, you have three options:

Fixing the rebase conflicts

Fix the conflicts within the files, and then when you are happy with the result, add the files to the stage

And then continue with your rebase:

Since git is trying to apply each individual commit on top of its new place in the tree, you may have to resolve more conflicts! One way to reduce the pain is to make sure your commit history is clean and that there’s not a whole lot of overlap in commits on particular files. You can keep your history clean using interactive rebase (see below).

Skipping a commit

I don’t recommend skipping commits when rebasing, but you can perform them with this command:

Aborting a rebase

If you are dealing with a conflict and would like to rollback your rebase, all you need to do is type:

The state of your working tree will be reverted to what it looked like before you started rebasing. Abort whenever you feel uncomfortable with what rebase is doing.

Interactive rebase

You can use rebase to modify your history in an interactive, powerful way. In most cases you’ll want to just want to tell git that you want to interactively rebase the last X commits on your branch. For example, if you would like to rebase the last 3 commits on your current branch, you can do:

This will give you a list of commits and some options for how to interact with them. The most recent commits are at the bottom.

When you save this file, git will write the new changes onto the branch. If you remove all the lines before saving, git will abort the rebase.

Simple squash of history

To do a simple squash of the history, all you need to do is change the ‘pick’ to ‘squash’.

This will merge commit 92a9049 and b306a6 into one single commit and give you the option of editing the commit message.

Editing an existing commit

This technically isn’t a rebase, but I have found it very useful. Forget a file in your last commit? Found a typo immediately after committing? First add the updated versions of the files to your stage.

Then commit the staged changes with the amend flag.

This will overwrite your old commit with a new commit that contains both your old changes and your new changes.

Interactively amend a commit

You can also amend commits that are further down in your history by using an interactive rebase. Change the pick to an edit for the commit(s) you would like to edit.

During the rebase, git will stop at this commit and give you the chance to amend this particular commit. Make any changes you would like to make, add them to the stage with

and then amend the commit with

After you are satisfied with your changes to this commit, run

to continue the rebase. All other commits being replayed on top of this edited commit will now have new hashes.

Use fixup to amend a commit

Switching pick to fixup will merge the commit into a previous commit and keep the commit message of the previous commit. One alternative to interactively amending the commit is to make a new commit, and then use a combination of reordering and fixup to fix problems with a commit.

3. This is what it looks like:

You can then reorder and fixup:

The rebase will then squash the commits and discard the commit message talking about pep8 and pylint violations.

Check the upstream branch. Are there, in fact, new changes there? If your branch has the same commits, more or less, as the one on your local machine, continue. If not, see the section on Working with other people/across multiple machines below.

In order to get your upstream Github branch up to proper, sync, you will have to run:

But wait! There’s a catch.

Force-pushing is dangerous

Be very careful when doing a force push! You are essentially overwriting the history of the branch on the repo If you have not set your git defaults correctly, then you run the risk of overwriting all of the branches in the repo, not just the one you are intending to overwrite.

Force-pushing to master

If you do ever force push to master (whether intentionally or accidentally), be sure to send email to both dev@edx.organd edx-code@googlegroups.org. Internal and external developers create branches from and rebase onto master frequently, and the commits that you removed by force pushing will appear in any pull request from a branch created while those commits were still on master. This can be very confusing, so you should be sure to inform everyone affected when it happens.

Rebase to a common ancestor

Sometimes you want to rebase your changes onto master from a common ancestor. (Helpful ascii art is from the official git documentation.) This will probably only happen if you are working off a long-running branch or if you accidentally make a branch off another branch.

How to abort rebase

Check your version of git by running

SYNOPSIS

DESCRIPTION

If
is specified, git rebase will perform an automatic git switch
before doing anything else. Otherwise it remains on the current branch.

The commits that were previously saved into the temporary area are then reapplied to the current branch, one by one, in order. Note that any commits in HEAD which introduce the same textual changes as a commit in HEAD.. are omitted (i.e., a patch already accepted upstream with a different commit message or timestamp will be skipped).

Assume the following history exists and the current branch is «topic»:

From this point, the result of either of the following commands:

If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped. For example, running git rebase master on the following history (in which A’ and A introduce the same set of changes, but have different committer information):

First let’s assume your topic is based on branch next. For example, a feature developed in topic depends on some functionality which is found in next.

We want to make topic forked from branch master; for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:

We can get this using the following command:

then the command

would result in:

This is useful when topicB does not depend on topicA.

A range of commits could also be removed with rebase. If we have the following situation:

then the command

would result in the removal of commits F and G:

In case of conflict, git rebase will stop at the first problematic commit and leave conflict markers in the tree. You can use git diff to locate the markers ( rebase.useBuiltin

Unused configuration variable. Used in Git versions 2.20 and 2.21 as an escape hatch to enable the legacy shellscript implementation of rebase. Now the built-in rewrite of it in C is always used. Setting this will emit a warning, to alert any remaining users that setting this now does nothing.

Default backend to use for rebasing. Possible choices are apply or merge. In the future, if the merge backend gains all remaining capabilities of the apply backend, this setting may become unused.

Whether to show a diffstat of what changed upstream since the last rebase. False by default.

A format string, as specified in git-log[1], to be used for the todo list during an interactive rebase. The format will automatically have the long commit hash prepended to the format.

If set to true, git rebase will use abbreviated command names in the todo list resulting in something like this: