What does "branching is free" mean in Git?
I hear this a lot whenever Git is mentioned in comparison to other version control systems.
I haven't had the opportunity (?) to deal with others (SVN, etc.), so how is branching "expensive" in others?
Add a comment
|
6 Answers
The claim that "branching is free in git" is a simplification of facts because it isn't "free" per se. Looking under the hood a more correct claim would be to say that branching is redonkulously cheap instead, because branches are basically references to commits. I define "cheapness" here as the less overhead the cheaper.
Lets dig in to why Git is so "cheap" by examining what kinds of overhead it has:
How are branches implemented in git?
The git repository, .git mostly consists of directories with files that contain metadata that git uses. Whenever you create a branch in git, with e.g. git branch {name_of_branch}, a few things happen:
- A reference is created to the local branch at:
.git/refs/heads/{name_of_branch} - A history log is created for the local branch at:
.git/logs/refs/heads/{name_of_branch}
That's basically it, a couple of text files are created. If you open the reference as a textfile the contents will be the id-sha of the commit the branch is pointing at. Note that branching does not require you to make any commits as they're another kind of object. Both branches and commits are "first-class citizens" in git and one way is to think about the branch-to-commit relationship as an aggregation rather than a composition. If you remove a branch, the commits will still exist as "dangling". If you accidentally removed a branch you can always try to find the commit with git-lost-found or git-fsck --lost-found and create a branch on the sha-id you find left hanging (and as long as git hasn't done any garbage collection yet).
So how does git keep track of which branch you're working on? The answer is with the .git/HEAD file, that looks sort of like this if you're on the master branch.
ref: refs/heads/master
Switching branches simply changes the reference in the .git/HEAD file, and then proceeds to change the contents of your workspace with the ones defined in the commit.
How does this compare in other version control systems?
In Subversion, branches are virtual directories in the repository. So the easiest way to branch is to do it remotely, with a one-liner svn copy {trunk-url} {branch-url} -m "Branched it!". What SVN will do is the following:
- Copy the source directory, e.g.
trunk, to to a target directory, - Commit the changes to finalize the copy action.
You will want to do this action remotely on the server, because making that copy locally is a linear-time operation, with files being copied and symlinked. This is a very slow operation, whereas doing it on the server is a constant time operation. Note that even when performing the branch on the sever, subversion requires a commit when branching while git does not, which is a key difference. That is one kind of overhead that makes SVN marginally less cheap than Git.
The command for switching branches in SVN, i.e. svn switch, is really the svn update in disguise. Thanks to the virtual directory concept the command is a bit more flexible in svn than in git. Sub directories in your workspace can be switched out to mirror another repository url. The closest thing would be to use git-submodule but using that is semantically quite different from branching. Unfortunately this is also a design decision that makes switching a bit slower in SVN than in Git as it has to check every workspace directory which remote-url it is mirroring. In my experience, Git is quicker to switch branches than SVN.
SVN's branching comes with a cost as it copies files and always need to be made publicly available. In git, as explained above, branches are "just references" and can be kept in your local repository and be published to your discretion. In my experience however SVN is still remarkably cheaper and more performant than e.g. ClearCase.
It's only a bummer that SVN is not decentralized. You can have multiple repositories as mirrored to some source repo but synching differing changes multiple SVN-repositories is not possible as SVN does not have uniquely identifiers for commits (git has hashed identifiers that are based on the contents of the commit). The reason why I personally started using git over SVN though is because initiating a repository is remarkably easier and cheaper in git. Conceptually in terms of software configuration management, each divergent copy of a project (clone, fork, workspace or whatever) is a "branch", and given this terminology creating a new copy in SVN is not as cheap as Git, where the latter has branches "built-in".
As another example, in Mercurial, branching started out a bit different as a DVCS and creating/destroying named branches required seperate commits. Mercurial developers implemented later in development bookmarks to mimic git's same branching model though heads are called tips and branches are bookmarks instead in mercurial terminology.
-
-
2From your own source:
This command causes a near-instantaneous commit in the repository, creating a new directory in revision 341. The new directory is a copy of /calc/trunk.- Creating the branch is trivial in SVN, unless you're explicitly making a copy of every file.– BobsonCommented Jul 9, 2013 at 18:27 -
@Bobson I was thinking about rewriting the bits on branching, since I'm doing a lot of handwaving regarding that, but my point still stands that a commit is required to create a branch while in Git it's not. In my humble experience I still feel though that switching branches in SVN is slower than in Git but I can't point to any specific reason why.– SpoikeCommented Jul 10, 2013 at 6:30
-
2@Spoike - Switching, certainly. And a commit is definitely required. I made an edit to clarify the bit I had a problem with. Feel free to revert it if you prefer.– BobsonCommented Jul 10, 2013 at 13:24
The real cost of a branch is merging it. Git makes this easier than some other source control systems. See Stack Overflow question How and/or why is merging in Git better than in SVN?.
answered Jun 23, 2013 at 5:42
-
5Strictly, Git only makes it easier than some other SCMs. Commented Jul 9, 2013 at 9:30
In Git, a branch is just reference to a commit to the local repo. Creating it is very cheap, no network at all. Not quite free (you've got to type a command), but damn near.
Branching isn't particularly expensive in SVN - it's just a copy, which is a very cheap commit. SVN does have a central repository model, so it's a network access, but not a horrible one.
In the venerable CVS, on the other hand, branching is VERY expensive. Basically, CVS branches involve adding a tag, but in CVS that means that EVERY FILE AFFECTED has to be modified. Each file is re-written to include the new tag. That's horribly expensive. And if your repository is big, it's also horribly slow. In fact, if you're on a big project, it's slow enough that some folks tend to avoid making branches if they can.
answered Jun 23, 2013 at 2:29
-
4With Git, it's even less than a commit - a branch is just a label. And SVN sounds as expensive as CVS, since they both copy all files.– IzkataCommented Jun 23, 2013 at 5:39
-
8@Izkata: if we see from user point of view - yes, all files are copied, from implementation (and performance) point of view - no, just a record about copy is added. Commented Jun 23, 2013 at 6:11
-
-
6@Izkata SVN creates pointers and references, it doesn't copy everything. Commented Jun 23, 2013 at 13:55
-
2A Git branch is not a commit, it's just a reference to a commit that can be moved around freely to other commits. Think of a Git repo as just a tree of commits, and branches as sticky notes that can be freely moved around to different commits on that tree. Commented Jul 9, 2013 at 12:27
It is 'free' (in this context 'free' really means quick and easy and not taking up space) because in some older version control systems a branch was a complete copy of the code at that point, so branches took up a lot of space and it was easy to end up with a lot of different completely full versions of the software lying around, which then took management. In others it wasn't a complete copy of the code but every file still needed to be modified for a tag so was slow and painful ('costly').
git's branches are essentially labels pointing at a commit and thus avoid the above issues.
answered Jun 23, 2013 at 15:05
SVN's branching is as free as Git's. It's just a bit of housekeeping data that says where the branch starts, no changes to the stored files whatsoever. A 'copy' in SVN is like adding a symlink to a Unix directory. Note that the SVN branch will not require a network trip until you commit your working copy changes (but there's not much point having a SCM if you don't commit off-local at some point).
Note that a Git branch will also involve some housekeeping - like adding that tag internally - that will have to be stored somewhere when you commit. It's not a big deal at all, which is why it's called 'free'.
answered Jun 23, 2013 at 10:09
Another aspect of "free / cheap / expensive" is to do with how much is costs in terms of developer resources to deal with the downstream consequences of branching; i.e. the process of merging changes from branches.
And here, merging branches in DVCS systems like Git and Mercurial is easier than in older systems ... because the DVCS systems do a much better job of tracking the history of the versions in the graph; i.e. where previous branching an merging has occured. This makes merges more accurate, reduces unnecessary conflicts and ... makes merging subjectively "easier" or "less scary" for the developers involved.
