Forking vs Branching in an enterprise context

I'm curious to know what DVCS strategy people use in enterprises.

The Github model is based on forks because in open source projects you have some trust issues and your probably don't want anyone to be able to update your code. However, in an enterprise context the trust issue is not as critical and branches might be a more suitable option for DVCS in terms of maintenance (less repos, less permissions to manage).

So, the question is simple: do you replicate Github model and use forks for new features or release with some sort of pull requests mechanism or would you rather work with branches.

This post might help peop开发者_Go百科le to get some insights about the strategy they should use if they think about going to DVCS in their own company.

---

Note that GitHub support both models:

• for sensitive repos, you can fork them (clone at the GitHub server side), in order for other collaborators to own the fork, and to push freely to it.
• for collaborative repos, with many collaborators, you can create an organisation, in which you manage all your collaborators.

For non-GitHub repos, an extra authorization layer like Gitolite support personal branch precisely for isolating contributor's contributions in their own branch, avoiding the need to provide n clones (forks) for a given repo.

---

I think you will get some pretty strong opinions on this question!
Where I work, we follow a model where

• I and one other person have full access to a machine containing the company's official repositories, and
• we have several developers who have read access. They will make changes, pull/merge from eachother/us, and occasionally
• we will pull revisions we approve and push them to our company's official repositories.

---

See http://progit.org/book/ch5-1.html for more extended reading on this topic.