Behind the Scenes at Jungle Disk - Non-blocking Pull Requests
NOTE - In this article, Pull Request (PR) refers to the Github Pull Request feature.
Mailing list based projects usually prefer patch series to be sent to the list
instead of git-request-pull.
Code Review Cycle
When a branch is ready [1] to be merged upstream, it is usually sent for a code review by the maintainer(s) or co-worker via a Github Pull Request. Depending on various factors, it may take several revisions or just some time until it is merged in. This should not be an impediment to continued development, even on new features that are dependent on commits in the PR.
Topic Branches
Once a branch has been proposed for inclusion, that branch should be treated
as frozen with no new commits added. Instead another branch should be created
based on the HEAD of the PR’d branch.
A---B---C master
\
M---N---O pr_topic
\
Y---Z new_topic
In doing so, work on new features continues along in the new working topic branch. If the code reviewer requests changes to the PR’d topic branch, it is then easy to go into it and update the commits.
Updating Commits
Updating the commits in the PR’d topic branch using the [rebasing][1]
techniques previous covered will rewrite those commit, and therefor rewrite
the history. Assuming that commit N needed a fix or change, both N and
O will be rewritten.
A---B---C master
\
M---N'---O' pr_topic
\
N---O---Y---Z new_topic
Now the PR’d topic branch can be force pushed back to the Github fork, and the PR will automatically update with the fixed commits.
Rebasing
Our working branch is now out of date since it is based on commit O not O'.
This can be remedied by rebasing it on pr_topic.
git rebase -i pr_topic
A---B---C master
\
M---N'---O' pr_topic
\
Y---Z new_topic
Notice that after the rebase the old commits N and O are no longer
reachable in any of the branches. They still exist in the git repository.
If needed they can be resurrected if you know the SHA of them.
To do so start a new branch based off M
git checkout -b n_and_o_branch SHA(M)
NOTE: SHA(M) is the SHA of the commit M.
Then rebase the branch on top of itself.
git rebase -i HEAD
The only operation will be a noop.
noop
# Rebase ec53f5b..ec53f5b onto ec53f5b (1 command(s))
#
# 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.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
Simply pick the two commit SHA’s of N and O.
pick SHA(N)
pick SHA(0)
# Rebase ec53f5b..ec53f5b onto ec53f5b (1 command(s))
#
# 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.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
The repo should now look like this:
A---B---C master
\
M---N'---O' pr_topic
\ \
\ Y---Z new_topic
\
N---O n_and_o_branch
This method of stitching together a branch from random SHA’s is a very handy
alternative to using cherry-pick multiple times.