Suppose you have a fork of some GitHub repository. You have made some changes in it that fix multiple bugs and add some new features. Now you want to send your work to the main repository.
If you send your work as a single pull request, it may be hard to process for the core team, since it spans multiple issues and multiple features are added. Moreover, the core team may have its own opinions regarding which features are needed and which not; they may want to partially accept your work.
It is better to split the work into multiple pull requests. But what to do if your commits are highly monolithic? That is, commits for issue A, followed by commits for issue B, then some commits for A again, and then some for B again?
How to restructure your work, so that it can be sent in separate, modular pull requests?
The idea is to make several branches, each one containing commits related to a single particular issue. Moreover, since the commits may be monolithic, we will restructure them.
First, we will bring our local repository to the state of the upstream we’re going to send pull requests to. Then, we will create the branches, one for each issue we solved. Finally, to each branch we will apply the entire diff between it and our master with our work (effectively bringing it to the state of our master) and hand-pick the changes to commit for a given issue.
Assuming there’s a remote to the main repository named
upstream in your local repository, your own work is in the
master branch of your local repository and you want to send pull requests to
upstream/master, here is how to do that:
git fetch upstream && git checkout upstream/master.
git checkout -b issue1
mastercontains your work) and apply it to the current branch:
git diff head master | git apply
git add -i. Use the interactive menu to select which files and hunks to stage.
git clean -f; git reset --hard