15

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:

  1. 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?
  2. 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.

Improve this question

3 Answers 3

Reset to default
7

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?

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.

Improve this answer
3

The fork-per-developer approach is a very good approach if you value code reviews and code quality. The nice thing about using pull requests is that it shifts the responsibility from the maintainer to the developer.

The developer wants to get his code into the main branch, and requests it's inclusion.

This is much different context than the old model where people commit, and later the reviewer had to tell them "oh, this thing you did a few weeks ago wasn't so good, fix it now."

We use this model in our company. Pull requests made code requests viable, encourage discussion of other peoples code and generally helped with code quality, even with developers who were first against the new tool. I feel that it also made people take code reviews more seriously, because the reviewer has to actively merge the code into the main branch, instead of just saying 'ok' or 'not ok' after code was already commited.

Improve this answer
1

I would not do all the forking and branching for everything. That is a good model for open source gems on github, but your model is within a organization that would normally have a higher level of trust about changes.

A major point of source control is that you can see, backout, reverse, etc. changes. Doing a high number of forks and branches in your situation is overkill IMHO.

I would reserve branches for things like: version upgrades, changing one of the technology pieces, working on a submodule for 3 months that has little in common with the main base.

I might not fork at all within an organization. That mode seems more suited to open-source projects which are different in nature to in-house ones.

I would switch your focus to testing and code reviews. Are folks writing tests? Are they good? Are code reviews done?

Improve this answer
4
  • 1
    We don't really write tests so much; we review each other's code semi-frequently. Tracking bugs, and implementations to solutions is really the most important to us right now. I think everyone would agree that tests are good in theory, and are much easier to implement on a project starting from zero; but we've got a lot of legacy projects which would take a huge for writing tests. I generally agree about forking and branching. We're coming from HG so having short-term branches which aren't actually part of the public history seems weird to us, but I definitely see the purpose.
    – Jim Rubenstein
    Feb 28, 2012 at 2:33
  • I actually don't see the problem with a big code base of existing functionality. Tomorrow when you do a big fix, write a test, then for the next feature, write a test. You don't have to go back and write old ones. You just need to start writing new ones. Do it enough and there's a good chance you'll write the test first. That's professional software development of software that counts.
    – junky
    Feb 28, 2012 at 3:26
  • btw, personally I use git and find the fact that it has a local repository, as opposed to svn say where you commit straight to remote (no push/pull) helps me get something working locally first anyway. It's easier 'cos I can still add and commit without the final push until I am ready.
    – junky
    Feb 28, 2012 at 3:28
  • Unless you use ClearCase dynamic view (which, if you ever tried, you'd know is PITA to use), you are forking for everything, because each checkout is really a fork, just one that in centralized version control systems can't contain multiple revisions. In decentralized and distributed systems (git is one) it can and is a regular fork.
    – Jan Hudec
    Feb 28, 2012 at 12:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.