github team workflow - to fork or not?

Question

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?

Answer 1

I think your fear of forking comes from SVN's less than stellar merging - because it's not the forking that causes the trouble - it's the merging.

Dive in - you'll find it's actually great! You don't need to over-fork (don't fork for every change in every file), but you can fork for features, and merge back in.

Think of GitHub as several versions worth of improvement on many of the core concepts in source control.

The concept of a "stable" branch, and an "active development" fork also cover many of these issues if you're hesitant to go forking. :P

Answer 2

We've tried both, with developers who are very at home in svn. And if you are a bunch of developers already working together and trusting each other with commit rights, you will probably find it easier to just keep a single, central repo at git and add you all as collaborators that that repo.

We still occasionally do private forks, but that's typically for exotic changes or 1-person tests that the rest are typically not interested in, but that we wish to store remotely anyhow.

I would start with a single, central repo and just work with git for a while. Maybe the private fork will grow on you, maybe not. Either is fine.

Answer 3

In git, a fork is really just another branch. With the fork-for-each-developer workflow, you're effectively mandating that each developer has a public (remote) branch to track their development changes. This is helpful for being able to collaborate directly (peer-to-peer) between developers. You will have to merge each developer's changes into the central repo in any case, so I don't think there's much overhead added by this.

Answer 4

For a small team of 2-3 developers it's okay to use branching on the repo to manage fixes and features. The issue is when you have more developers than that and more features and fixes that are being developed.

When that is the case, your main repo in Github will have hundreds of branches; some will be old and forgotten and unmerged. Those old, forgotten branches can affect git push performance too.

You will also have issues with collaboration where someone is force-pushing on a shared branch that's on the repo. That means no one can collaborate properly on that branch as a force-push is a rewrite of the history.

Forking a repo makes it easier to track which branches are work in progress and which ones are good to go. It keeps the main repo cleaner.

However, your testing infrastructure may be relying on using the main repo so it may be harder to test changes in your forked repo unless you've pushed the branch to the upstream. It can be tricky to figure out when branching and forking are best but in general, when the team has more than 4 people and there are lots of fixes and features, forking is the best option.