GIT Rebase Workflow

In a nutshell: Take commits from a branch which was edited in parallel to another branch (e.g. take commits from a feature branch which evolved while master evolved as well) and rework them as commits on top of master. This turns a history with two parallel branches into a linear history with only one branch.

This is useful on later evaluating the history, e.g. with git bisect, but care needs to be taken to not make the downstream experience difficult.

References

Example

Assume a feature branch, called feature_branch1, another feature branch, called feature_branch2 and the master branch. Both feature branches are independent, and could be put linearly after each other, making the GIT history very easy to read. Because they both branched off at the same time from master, they have the same parent and are thus parallel.

When feature_branch1 is now merged to master, feature_branch2 needs to be rebased on master. This changes the commits, so it should only be rebased if it hasn't been merged into the upstream repository or in other feature branches already.

git checkout feature_branch2
git fetch upstream
git rebase upstream/master

Now the feature branch is on top of master. The issue is now that if both feature branches were in pull requests already, the pull request needs updating:

# delete old branch / PR
git push origin :feature_branch2
# push rebased branch
git push origin feature_branch2

If the PR was auto-closed by Github, it might need to get recreated.

Translations of this page:


Quick Links

QR Code: URL of current page