Say someone submits a PR to public/master on Github.
Is there a way to merge that PR into a different branch? Otherwise, looks like I have to merge into public/master, then merge that backwards into a development/staging branch. It's like having people do a hotfix and then merging the hotfix into a development branch, which is something we normally should want to avoid right?
Seems to make more sense to have people track and submit PRs to a staging/development branch instead of master.
What is the best way to do that? The tricky part is that currently the staging/development branches are private. Sounds like I have to make one development branch public, and then direct people to branch from and submit PRs to that branch?
By definition, you can't target a PR for a branch that you don't know exists.
Your history might look something like this:
*--A--B--C [develop] (private)
\
... D--*--*--E [master]
\
F--G--H--I [myfeature] (PR for this)
There are two problems here. (1) The PR for myfeature can't target develop, because develop is private, and not visible to the author of myfeature. (2) The develop branch has some commits (in this case B and C) that are also private.
The second problem is the more important one. If commit B conflicts with commit G, then no matter how you try to get the changes from myfeature into develop, you will have to be the one to resolve that conflict. This is not ideal; I have found that it is much easier for the author of the PR to have the responsibility of resolving conflicts, rather than the maintainer.
With that said, there are two solutions: go public, or rebase and merge.
Go Public
This is the solution that I recommend, because it will be the easiest long-term solution. You can push your develop branch to GitHub and make it public. This would allow other users to branch off of develop and send PRs against it.
You mentioned that you have certain private files in your develop branch. Depending on what you need those files for, you may be able to ignore them, or extract sensitive values out of them to be loaded at runtime. It is best to never have private files anywhere in your repo, because among other reasons, you may accidentally make develop public.
If you use this solution, then you are already pretty close to using the Git Flow workflow, which I also recommend.
Rebase and Merge
If you absolutely can't make develop public, then you need to rebase and merge. First, do:
git rebase --onto develop master myfeature
Your history will now look like this:
F'--G'--H'--I' [myfeature]
/
*--A--B--C [develop]
\
... D--*--*--E [master]
\
F--G--H--I
You can then merge into develop as normal:
git checkout develop
git merge --no-ff myfeature
Giving you:
F'--G'--H'--I' [myfeature]
/ \
*--A--B--C---------------J [develop]
\
... D--*--*--E [master]
\
F--G--H--I
The other downside of this solution is that as far as GitHub is concerned, the PR hasn't been merged yet, so you'll have to close it manually. Related to this, the user who submitted the PR won't be able to see that it has been merged until you release new changes from develop to master.
