github team workflow - to fork or not?
- by aporat
We're a small team of web developers currently using subversion but soon we're making a switch to github.
I'm looking at different types of github workflows, and we're not sure if the whole forking concept in github for each developer is such a good idea for us.
If we use forks, I understand each developer will have his own private remote & local repositories. I'm worried it will make pushing changesets hard and too complex. Also, my biggest concern is that it will force each developer to have 2 remotes: origin (which is the remote fork) and an upstream (which is used to "sync" changes from the main repository). Not sure if it's such a easy way to do things.
This is similar to the workflow explained here: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow
If we don't use forks, we can probably get by fine by using a central repo creating a branch for each task we're working on, and merge them into the development branch on the same repository. It means we won't be able to restrict merging of branches and might be a little messy to have many branches on the central repository.
Any suggestions from teams who tried both workflow?
