If you are reading this article, you obviously care about GIT like lot of developers do and if you haven’t had a chance to get some taste of GIT, I think it’s time to wake up.

GIT is much more than a version control system, it can be used as CMS, workspace manager etc. It will take a mind shift for anyone coming from SVN background to get used to some of the concepts & features that GIT offers. So, the main purpose of this article is to help them by giving ideas on what to expect from GIT and how it’s different from SVN from high-level.

Alright, here it goes…

  1. GIT is distributed, SVN is not:

    This is by far the *core* difference between GIT and other non-distributed version control systems like SVN, CVS etc. If you can catch this concept well, then you have crossed half the bridge. To add a disclaimer, GIT is not the first or only distributed VCS(version control system) currently available. There are other tools like Bitkeeper, Mercurial etc. which also work on distributed mode. But, GIT does it better and comes with much more powerful features.

    GIT like SVN do have centralized repository or server. But, GIT is more intended to be used in distributed mode which means, every developers checking out code from central repository/server will have their own cloned repository installed on their machine. Let’s say if you are stuck somewhere where you don’t have network connectivity, like inside the flight, basement, elevator etc. :) , you will still be able to commit files, look at revision history, create branches etc. This may sound trivial for lot of people but, it is a big deal when you often bump into no-network scenario.
    And also, the distributed mode of operation is a biggest blessing for open-source software development community. Instead of creating patches & sending it thro emails, you can create a branch & send a pull request to the project team. It will help the code stay streamlined without getting lost in transport. GitHub.com is an awesome working example of that.

    There were some rumors that the future version of subversion will be working on distributed mode. But, it’s still an unknown at this point.

  2. GIT stores content as metadata, SVN stores just files:

    Every source control systems stores the metadata of files in hidden folders like .svn, .cvs etc., whereas GIT stores entire content inside the .git folder. If you compare the size of .git folder with .svn, you will notice a big difference. So, the .git folder is the cloned repository in your machine, it has everything that the central repository has like tags, branches, version histories etc.

  3. GIT branches are not the same as SVN branches:

    Branches in SVN are nothing but just another folder in the repository. If you need to know if you had merged a branch, you need to explicitly run commands like svn propget svn:mergeinfo to verify if it was merged or not. Thanks Ben for pointing this feature :) .
    So, the chance of adding up orphan branches is pretty big.

    Whereas, working with GIT branches is much more easier & fun. You can quickly switch between branches from the same working directory. It helps finding un-merged branches and also help merging files fairly easily & quickly.

  4. GIT does not have a global revision no. like SVN do:

    This is one of the biggest feature I miss in GIT from SVN so far. As you may know already SVN’s revision no. is a snapshot of source code at any given time. I consider that as a biggest breakthrough moving from CVS to SVN.
    Since, GIT & SVN are conceptually different, I don’t know how you can mirror that feature in GIT. If anyone know of any tricks that can do this, please feel free to share it in the comments.
    Update: As some of the readers pointed out, you can use GIT’s SHA-1 hash key to uniquely identify the code snapshot. It may not exactly replace SVN’s easily readable numeric revision no. but, it kind of serves the same purpose.

  5. GIT’s content integrity is better than SVN’s:

    GIT contents are cryptographically hashed using SHA-1 hash algorithm. This will ensure the robustness of code contents by making it less prone to repository corruption due to disk failures, network issues etc. Here is an interesting discussion on GIT’s content integrity – http://stackoverflow.com/questions/964331/git-file-integrity

Are those only 5 differences between GIT & SVN? Well, not really :) . I thought 5 rhymes with “fundamental” & “fascinating”, I came up with that number. If you can think of a better one than the one’s listed here, feel free to share them, I might be willing to trade them with these ones.

Comments, questions, curses?

45 thoughts on “5 Fundamental differences between GIT & SVN

  1. Hi Rudy,

    Thanks for your response. Tagging is a slightly different concept than what subversion offer in the form of “global revision numbers” – http://svnbook.red-bean.com/en/1.0/ch02s03.html. Almost every VCS (including SVN & GIT) will have option to tag a code repository with a specific label name like (v3.6.8, v4.0 etc.).

    But, in SVN global revision numbers are auto-generated numeric values (like 51225555) and it applies to the entire tree of the repository. Even a single file checkin will create a new revision number, which in later case you will be able replicate the VCS snapshot by specifying that revision number.

    Hope that helps.

  2. SHA-1 is not an encryption function, it is a hash function.

    Subversion has revision numbers, because it can. In a distributed SCM, you cannot use revision numbers in the same way, because revision numbers in different repositories of the same project could disagree about their contents.

    Git uses SHA-1 hashes as identifiers, so does Monotone. Mercurial has revision numbers, but they are locally bound to a repository, changesets are identified by an 160-Bit-hash (maybe SHA-1, could not find out). Bazaar has revision numbers, but they are extremely complicated and to identify a changeset, they have a long generated string called revision ID (so revision number and revision ID is not the same there).

    Personally, I think the main fundamental differences are #1 (which implies #2 and #4) and #3 (I never branched with Subversion, with Git I do it all the time), while #5 seems to be more of a technical issue.

  3. Hi Timo,

    Thanks for pointing that out. Yes, SHA-1 cryptographic hash function is used for maintaining data integrity. I’ll update the post.

  4. Timo Reitz got it right, but I’d like to clarify (just in case) that GIT’s SHA-1 hashes double as the global revision numbers you’re looking for. Sure, they’re less intuitive and harder to type than “31337″ for a revision number, but the serve the same purpose.

  5. Pingback: Tweets that mention 5 Fundamental differences between GIT & SVN | BoxySystems Inc. -- Topsy.com

  6. Pingback: Revue de presse, semaine 38 - Espace de fouille

  7. I think the article was good (having used svn almost exclusively for several years and only reading about git), however svn has gotten better at merging, so I found this statement a little bit off:
    “It’s almost impossible to know if you merged that branch or not.”

    $ svn propget svn:mergeinfo

  8. Hi Ben,

    Thanks for pointing this out. I didn’t know this feature exist in SVN :)

    I’ll rephrase the article to reflect this.

  9. Lou is absolutely right.

    The SHA-1 hash of a commit *is* the revision. You can check out such a commit using e.g.

    git checkout 324dfeb

    and you can be sure that *everything* is at the state of that commit.

    Please be aware also that you don’t need to use the full SHA-1 hash, only enough so that it’s unique. Normally, 5-7 chars are absolutely enough.

    I can only encourage http://progit.org/ for a deeper understanding of GIT. It’s a great book.

    No, I’m not paid to write this. I’m just an incredibly satisfied customer. Paying the author is optional (but I’d suggest to do it anyway at the nice price of 9$) since the whole book is available in a git repository.


  10. As others have said, the hash fulfils the same function as an SVN revision, uniquely identifying a specific commit. It’s not much use as a version number though, since it has no meaningful order – you can’t look at two commit hashes and instantly know which is newer.

  11. Pingback: JASON WU的网络日志 » GIT和SVN之间的五个基本区别

  12. Pingback: GIT和SVN之间的五个基本区别

  13. Pingback: GIT, CVS , SVN… | aninki.net

  14. Pingback: links for 2011-04-18 – Confessions of a Flash Addict

  15. Pingback: 5 Fundamental differences between GIT & SVN « esc

  16. Pingback: 转一篇:GIT和SVN之间的五个基本区别 | 快乐云の小屋

  17. Pingback: ความแตกต่างระหว่าง Git กับ SVN | ArmNo.in.th

  18. Hi,As far as the source code snapshot is concerned it is not found in GIT but GIT has another tool support called Gerrit for source code reviews.Any change made in the code by the developer is recorded n Gerrit.

  19. “I thought 5 rhymes with ‘fundamental’ & ‘fascinating’” Actually that’s alliteration not rhyming :) .

  20. Pingback: 5 Fundamental differences between GIT & SVN « phuongdvk47

  21. GIT SHA-1 and SVN revisions are not the same and not interchangeable for their purpose. GIT SHA-1 tags are 40 *random hex digits* while SVN revisions are *incremental decimal numbers*. By looking at two revisions, you can easily tell which one is ‘older’ and which one is ‘newer’. Cant do that with SHA-1 tags.

    Furthermore, it is not completely impossible to have such functionality implemented in git (unlike as someone suggested above). We don’t need to version all the ‘commits’. Just the ‘push’s. It should be technically possible to add a revision on each *push*, which is what most people will care about in a centrally managed repo. In fact, something like this can be done even today with a ‘post-push’ hook that adds an incremental tag on each push.

  22. Pingback: GIT和SVN之间的五个基本区别 | Ediclot 's Blog ——

  23. Pingback: Git和SVN之间的五个基本区别 | 博客 - 伯乐在线

  24. Pingback: GIT和SVN之间的五个基本区别 « 卢文荣博客

  25. Thanks for the article.. after reading this (and a few others), I’ve chosen Git (EGit for Eclipse) to start a new project in.

    Subversion == I hate that broken thing.
    CVS == Always worked well, but I’m tired of specifying ASCII/binary for backup files!

    Git == I *really* like the idea of flexibility to branch, work & checkin progress — only ‘pushing’ work to the server repository when complete.

    No more co-workers complaining, that your ‘partly complete’ work, shared to promote early collaboration, broke their thing!

  26. For build machines I can recommend:
    $ git rev-list --count --all

    lists the total number of commits bases on all branches. (replace –all with HEAD if you onl want the current branch)

    While this is a incrementing number for a single repository it is not easy to go from the number back to the actual code but they are useful for version numbers ;)

  27. Pingback: Using Git to Keep Your Website Updated | Dombieland.com

  28. I see Git’s advantages for distributed teams, that may not have access to server or need to branch a lot, or for ppl that walk a lot.

    But I see disadvantages like lack of revision number, lack of good tools, and risk or commiting only over local repo and forgetting to push back.

    With Subversion we can store it on a good host and be safe, and we know that every commit is immediately safe. Now Imagine these laptop travellers doing commit on them, for months without push, then somebody steal their laptop.

  29. Pingback: 더이상 나올 소프트웨어는 없는가 | Rubbish Philosopher

  30. Thanks a lot for your blog. I am using SVN for some years but will start using Git in a few days and your overview gave me a good impression how to work with Git.

    Since I’ll need to create a new repository it would be helpful to know if the TTB layout (which I mainly used in the SVN world) is also good in the Git world?

    TTB Layout:

    - /tags/
    - /branches/
    - /trunk/

  31. Pingback: GIT和SVN之间的五个基本区别 - Sina App Engine - 开发者第964503个问答

  32. Pingback: Version control | NDerison

  33. Pingback: GIT和SVN之间的五个基本区别 – 子任:代码思考人生

  34. Pingback: SVN Set Up on MAC | Simple

  35. Pingback: Git and Github | Tech Musings

Leave a reply


<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>