I have a common issue but I don't see a solid best practice for how to solve this. I am contributing to someone elses GitHub repo. I forked the latest Development branch to my repo. Now I want to apply pull requests one by one, making it very easy for each one to be evaluated and merged separately.
Specifically, I'm contributing documentation where the upstream author may want to cherry-pick which documents he wants, rather than all of them. I've had the issue in the past where I wrote a lot of docs into a single PR and it was dismissed as being too much. So now I'm doing a separate commit into my repo/branch for each of my pre-written docs, and I'd like to submit them for individual evaluation.
With the example upstream MainRepo and branch main-dev, and my ContribRepo branch upstream-dev, I have several commits with one new file in each. What is a "best practice" which will allow each commit to be merged or rejected without forcing an all-or-nothing action?
I don't think GitHub supports this from the browser UI. I know about cherry picking, and how to use that to pull commits from my own branches. But I've read that the upstream author needs access to a contributor's repo to cherry pick commits back to his own repo/branch.
It almost seems like I need to create a new branch in my repo for each document that I want to submit, which in some ways seems appropriate given that I'm considering each file to be a separate project. I'll do this but it seems like we're consuming a huge number of resources for a tiny event.
If I'm asking the wrong question about how to get out of a box that I shouldn't be in, please suggest a better approach to this (common?) challenge.
It's easy to make each change a separate branch. From the command line, do:
git checkout main-dev
git checkout -b my-first-work
git add .
git commit -m 'did some first work'
git push -u origin my-first-work
git checkout main-dev
git checkout -b my-second-work
git add .
git commit -m 'did some second work'
git push -u origin my-second-work
Continue like this for as many branches as you want. Then do a pull request of each branch.
That being said, I don't really see why they need you to work this way. They could easily work with a single pull request that had many commits on a single branch. There is no reason why they can't cherry-pick the ones they want.
They certainly "have access to your repo"! That is what github is all about.
But if that's what their standards are, they are the boss of their repo. Just work as above and hopefully they'll be happy.