_Quick Comparison of Forking and Branching
Forking and branching provide two ways of diverging from the main code line. Both Mercurial and Git have the concept of branches at the local level. The code that is branched (main trunk) and the branch know and rely on each other. Like a tree trunk's branch, a code branch knows about the trunk (original code base) it originated from.
Term fork (in programming) derives from an Unix system call that created a copy of an existing process. A fork is another way of saying clone. As DVCS hosting evolved, the term fork evolved. The Bitbucket software adds management to forks; forking a repository in Bitbucket has functionality you normally wouldn't associate with a DVCS clone. Whether you use either branching or forking, and to what extent, depends on your working environment.
There are lots of ways a team can work with and combine fork and branch functionality. You can google for discussions about this. Generally, for hosted systems, forks work well in situations where, as a repository admin:
- You don't want to manage user access on your repository.
- You want fine-grain control over merging.
- You expressly want to support independent branches.
- You want to discard experiments and changes easily.
The Bitbucket team recommends branching for development teams on Bitbucket; We use a modified form of Vincent Driessen's GitFlow technique. Bitbucket branches are useful when:
- You have a small group of programers who trust each other and are in close communication.
- You are willing to give the development team write access to a repository.
- You have a rapid iteration cycle.
Ultimately, though it is your choice – branch or fork – Bitbucket supports both.