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