views:

319

answers:

2

Can someone help me understand the difference between a branch, a fork and a clone in Git?

+1  A: 

Branch: Branches off of main repository on a current project. Think of these are like Stable, Beta, Experimental, Tested etc.

Fork: fork off main project and start your own fork of the project. Essentially leaving the main trunk and going on your own.

Clone: Make a clone of the project in a new directory. Creating a copy of a repository.

Here are some more good comments on branching/forking.
link text

Chris
+12  A: 

A clone is simply a copy of a repository. On the surface, it's result is equivalent to svn checkout, where you download source code from some other repository. The difference between centralized VCS like Subversion and DVCSs like Git is that in Git, when you clone, you are actually copying the entire source repository, including all the history and branches. You now have a new repository on your machine and any commits you make go into that repository. Nobody will see any changes until you push those commits to another repository (or the original one) or until someone pulls commits from your repository, if it is publicly accessible.

A branch is something that is within a repository. Conceptually, it represents a thread of development. You usually have a master branch, but you may also have a branch where you are working on some feature xyz, and another one to fix bug abc. When you have checked out a branch, any commits you make will stay on that branch and not be shared with other branches until you merge them with or rebase them onto the branch in question. Of course, Git seems a little weird when it comes to branches until you look at the underlying model of how branches are implemented. Rather than explain it myself (I've already said too much, methinks), I'll link to the "computer science" explanation of how Git models branches and commits, taken from the Git website:

http://eagain.net/articles/git-for-computer-scientists/

A fork isn't a Git concept really, it's more a political/social idea. That is, if some people aren't happy with the way a project is going, they can take the source code and work on it themselves separate from the original developers. That would be considered a fork. Git makes forking easy because everyone already has their own "master" copy of the source code, so it's as simple as cutting ties with the original project developers and doesn't require exporting history from a shared repository like you might have to do with SVN.

siride
A fork doesn't necessarily mean the developer isn't happy with the main repo. Typically, it means that another developer has read, but not write, access to that repo. The developer can fork the repo, make changes but since he can't write to the main repo he has to submit his changes as a patch. So, forking is also a means of encouraging collaboration without granting write access.
Bryce
I suppose that's true. I've only ever seen "fork" used in the context of creating a new, potentially competing version of a project.
siride
You could say that a fork is a branch that is not expected to be merged upstream
masonk