1

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.

TonyG
  • 1,432
  • 12
  • 31

1 Answers1

1

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.

JoelFan
  • 37,465
  • 35
  • 132
  • 205
  • JoelFan - could you elaborate on how someone cherry-picks commits from a pull request? As I said in the OP, I know how to cherry-pick from one of my branches into another, but when I PR, I don't know how the upstream can cherry-pick commits from there. Certainly the upstream dev has access to public forks/branches, but that seems to require the dev to reach out for updates when the whole idea of a PR+merge is for us to submit our contributions to them. This is where I come to wondering what the standard practice is for this scenario. Thanks! – TonyG Jan 26 '20 at 03:04
  • All the have to do is fetch your branch, checkout their branch, find the hash of the commit they want from your branch and cherry pick it with the cherry-pick command, then push their branch. Their branch then has your commit on it. – JoelFan Jan 26 '20 at 21:12
  • Makes perfect sense. I was looking for some other mechanism but if this is the way it's done then this is the answer. Thanks! – TonyG Jan 28 '20 at 16:10