A weird title, yes, but I've got a bit of ground to cover I think.
We have an organization account on github with private repositories. We want to use github's native issues/pull-requests features (pull requests are basically exactly what we want as far as code reviews and feature discussions). We found the tool hub by defunkt which has a cool little feature of being able to convert an existing issue to a pull request, and automatically associate your current branch with it.
I'm wondering if it is best practice to have each developer in the organization fork the organization's repository to do their feature work/bug fixes/etc. This seems like a pretty solid work flow (as, it's basically what every open source project on github does) but we want to be sure that we can track issues and pull requests from ONE source, the organization's repository.
So I have a few questions:
- Is a fork-per-developer approach appropriate in this case? It seems like it could be a little overkill. I'm not sure that we need a fork for every developer, unless we introduce developers who don't have direct push access and need all their code reviewed. In which case, we would want to institute a policy like that, for those developers only. So, which is better? All developers in a single repository, or a fork for everyone?
- Does anyone have experience with the hub tool, specifically the pull-request feature? If we do a fork-per-developer (or even for less-privileged devs) will the pull-request feature of hub operate on the pull requests from the upstream master repository (the organization's repository?) or does it have different behavior?
EDIT
I did some testing with issues, forks, and pull requests and found that. If you create an issue on your organization's repository, then fork the repository from your organization to your own github account, do some changes, merge to your fork's master branch. When you try to run hub -i <issue #> you get an error, User is not authorized to modify the issue. So, apparently that work flow won't work.
Best Answer
Depends on your team's scale, I guess. I used to work in a small team where we just had a single repo and features got their own branches within that repo. That worked just fine for us.
However, I now regularly contribute to a larger open source project where a few dozen people have access to the central repo. We still do all major development in personal repos and submit PRs for features so code can be reviewed, although bugfixes can be pushed directly. The main repo only carries master and release branches, keeping it free of clutter. Feature branches are in personal repos, so they can still be seen by others (making early PRs for them will alert others in the team that work on a feature is underway). I can recommend this workflow for any project with more than a handful of developers; the only downside to it is having to work with multiple remotes.