Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:

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?

share|improve this question

migrated from Jun 29 '11 at 14:21

This question came from our site for professional and enthusiast programmers.

to fork or not to fork – lukas Jun 29 '11 at 17:18
up vote 6 down vote accepted

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

share|improve this answer
If you replace all instances of "fork" with "branch", I agree. However, the question was about forking and dealing with two (or more) remote repositories. – David Harkness Oct 1 '12 at 15:40

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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