Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Sorry if this is a duplicate, I looked.

We're moving to Git. In Subversion, I'm used to having \trunk, \branches and \tags folders.

With Git, switching between branches will replace the contents of the working directory, so am I right to assume that the way we used to work just doesn't apply with Git?

My guess is that I'd have a repo folder with maybe a gitignore and readme.txt, then the folders for the projects that make up the repo, and that's it.

share|improve this question
add comment

2 Answers

up vote 10 down vote accepted

You will have "trunk", now called "master", you will have "branches" now called "heads" and you will have "tags", still called "tags", but they won't be folders, they will be "refs", labels to revisions that live in separate namespace inside the repository.

Subversion and Git have different ways to do branching. The basic subversion model is to have a directory tree with single global timeline and if you want to branch, you copy a subtree in another directory.

On the other hand Git has a directory tree with revisions that each defines it's parents, but each revision can have multiple parents (a merge) and multiple children (branches). So instead of having directories for branches, you get independently created revisions. The "refs" are just names associated with latest revision for given "branch".

This difference is fundamental to distributed version control. Git (and other distributed systems) does not have any central authority to keep the history linear, so revisions can be created independently on multiple repositories without knowing about each other and the system has to accommodate them. It turns out the generalization makes branching and merging a lot easier in general.

Note, that in Git, revisions are not on any branch. They just are and branches contain them. But once branch is merged, or proves to be dead alley, you can just delete the "ref" pointing to it and forget about it altogether (if you discard old trials, they will be garbage-collected eventually with git gc). This helps you avoid getting swamped in old experiments nobody remembers what they were about anymore.

share|improve this answer
    
Cool. No tags, branches and other folder nonsense is needed. Lovely. –  Luke Puplett Dec 3 '12 at 10:56
1  
@LukePuplett: Subversion's method of branching is rather unique. It comes from Perforce and I believe that's the only other version control system that has it. The fact that subversion does not make clear distinction what is a branch greatly complicates the merging algorithm. It gives some flexibility, but that flexibility isn't really supportable by 3-way merge, leading to a lot of difficult to understand corner cases. –  Jan Hudec Dec 3 '12 at 11:04
    
Even CVS (which is SVNs spiritual predecessor) didn't use that (rather strange) branches-and-tags-are-actually-directories approach. I'm not saying that CVS did branches well, but at least they where a "proper" concept instead of just a directory. –  Joachim Sauer Dec 3 '12 at 11:20
    
@JoachimSauer: I am not sure CVS is Subversion's spiritual predecessor. They set on a mission to make "better CVS", but they mainly took concepts from Perforce. –  Jan Hudec Dec 3 '12 at 12:14
    
@JanHudec: that may very well be, I don't know much about Perforce. What I meant is exactly that mission: be a good successor to CVS. –  Joachim Sauer Dec 3 '12 at 12:28
add comment

Just think of Git as a 3D view of the same data that you see in 2D in SVN - ie with SVN you branch your root and it appears as a copy shown as a new folder in the tree. With Git, when you branch it appears as a copy shown as a "layer" ontop of your existing tree. Once you realise that its pretty easy to conceptualise the difference.

With SVN you can still work the same way as Git - switch between branches will replace the single view of the codebase with the branched view, this applies whether you use svn switch or git checkout.

Obviously you can get a copy of a branch in SVN by checking out the branch to its folder location, which is the same as cloning a git repo to a different location on your disk.

Same applies to tags - you can label a git revision, or you can make a branch for a release. SVN tags are the same as branches, its only convention that they're called 'tags'. You could label (well, record the revision number) of a SVN repo to get a snapshot of a release too.

The differences between git and svn are more to do with how checkin and checkouts happen, not with the fundamentals of source control. The view of the code can be different (you'll never see a single view of the code tree that includes branches in git, and you can branch a partial repository in SVN, but these are ultimately minor differences)

share|improve this answer
add comment

Your Answer

 
discard

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.