Why the Heck is Git so Hard?

Why the Heck is Git so Hard?  The Places Model™
   … ok maybe not hard, but complicated (which is not a bad thing)
This post is aimed at those programmers having experience with SVN (or CVS) and who are about to embark upon learning Git.  Your road ahead will be complicated.
The post will show that one of the reasons (there are other) why going from the SVN model of source-control to Git can be so complicated comes from the fact that there are many more places for source to exist.  Rather than focusing on the warts, I hope this post will explain to newcomers the Places Model that will help motivate why Git is complicated (and yet amazing).

This model is one of the most important thing to understand about Git -- and memorize.  The actual command-lines are the arcana of accretion and arbitrary conflation, and are one of the reasons people get so frustrated with Git.  Just use stack-overflow.  Or even better, use this beautiful site.

SVN is Relatively Simple
In SVN there are only two different places source can exist:  your local directory and the remote repository.  All our interactions back and forth (checking out, committing, reverting, status)  are between these two places.  This is not too difficult to understand.  If we have N different interactions, then we only have to understand these N-interactions.
In the above diagram, I show three types of interactions for a SVN system.  Red interactions move source from the working directory place to the repository place.  Green interactions move source in the other direction (from the repository to your working directory).  And purple interactions are useful for getting information about both places. In this post we are going to ignore branching.  

Git: Increasing Places and Increasing Interactions

In Git, there are five places your source can exist:
  1. a stash,
  2. your local working directory,
  3. an index (or staging area),
  4. a local repository,
  5. and a remote repository. 
Knowing that these places even exist is often the first conceptual impediment for someone coming over to Git from SVN.  

Why do these Places Exist?
These places are part of the power and flexibility of Git over other systems.  

With an index, we can choose how to commit a multitude of changes, without having to commit to all our changes at once. This is a great flexibility.  With the local repository versus the remote repository, we turn Git into a distributed version control system, where each repository is conceptually just as equal to the next one.  With stash, we take advantage of the underlying content DAG to provide us an amazing convenience.

In between all of these places, we can (loosely) have the same types and number of interactions.  If we assume a well-orderedness to these places then we have to minimally concern ourselves with N*4 interactions.  

It’s not actually as many as N*4, as a lot of these operations don’t really occur that often (or at all), and because the ‘stash’ is not used that often (or, more accurately, is optional).  On the other hand, to increase our numbers, we also acknowledge that many interactions interact with multiple places at the same time, or between places that are not next to each other (consider git pull, for instance). In short, there are many more interactions that can be occurring.  A lot more than N.

This is the first great step to attaining enlightenment in Git:
  • knowing that there are five places
    • 3 that we use all the time,  (working directory, index, and local repo)
    • 1 we use when we interact with teams or want to back-up (remote repo)
    • 1 that we can use optionally as much as we like (stash)
  • and knowing that there are many interactions that can occur between these places and sometimes between more than two places simultaneously.

Knowing that there are many more interactions, gives you a framework to understand the bad parts of Git, the names of these interactions.  I highly suggest you use cheat-sheets like this while you are learning. I am not going to debate anyone about this.  It is a personal opinion that I hold, and I am comforted in knowing that I share this opinion with many others: the command-line usage is a pain in the butt.
If anything, the Places Model is not the reason Git is so hard.  Git is so hard because of the lack of clear mapping between the command-line and Git’s underlying models:  places, content, branching, and remotes.

You have been introduced to the first step in Git enlightenment:  the Places Model™.

You are Not Done!

The second step in attaining enlightenment in Git is learning the Content Model. Therein contained is knowledge of the objects of commits, blobs, trees, tags and the pseudo-objects of everything else: refs and refspecs, SHA’s, etc.
The Content Model

The third step is learning the Branch Model. The  Branch Model is built atop of the Content Model but follows the evolution of commits as they provide temporal DAG-like capabilities (aka ‘versioning’).
The Branch Model

This post will not seek to explain these next steps.  There are many other online books and posts which cover the fact that Git is essentially a DAG of content-hashed pointers to file contents (a content-addressable versioned file system all hidden in your .git directory).   I suggest the following to get you started:

Once you have a true understanding of these models, working with Git becomes easier.  Your day to day activities can now be understood within the context of manipulating your source through the temporal and spatial landscape that these models provide.

One could argue that there is actually a fourth step, which is a mixture of the Places Model and the Branch Model, in which we concern ourselves with the lifecycle and availability of branches in different places:  the Remote Model.  

Understanding remote refs and how tracking branches work is a first step in the Remote Model.  This model is also the source of a lot of opinion, best-practices, and team-building.  If you have ever heard of  git-flow, the git rebase versus git merge debate, and private versus public branches,  then this is the realm of the Remote Model.  It is also here that you will have enter the hosted world of GitHub and its competitors.

Good luck on the winding road ahead. Maybe one day you can be involved in something like this.

Personal Context For Wanting to Write this Post
I have been using Git since about 2007 (6 years now).  I am not great at it, mainly because I have not used it constantly.   I often go months without programming or am forced to use a client’s source control system.

Previous to Git, I had researched other distributed VCSs like Monotone and Darcs.  I even released my only-ever open-source project, back in 2006, from a Darcs repository (I still love the elegance of the Darcs model and command-line). In the end Git and Mercurial are the ones that have flourished. (Yes. I know bazaar and monotone are out there).

Having to go months without using Git and then coming back to it, I am constantly reminded of how complicated it is. Inevitably I have to review git reset and tend to forget when to use git checkout versus git branch.  If my memory were better perhaps I wouldn’t be writing this post.

I am in awe of Git’s promiscuous branching, speed, flexibility, and distributed nature. The versioned content-addressable file-system and DAG that underpins the repository was a genius choice, and one that was even controversial in the beginning.  Previous systems stored and calculated deltas.

With all that there is to like about Git, I have always been so frustrated at the lack of clarity in the command-lines for doing anything beyond the simplest action.  Heck, even the simplest actions are harder than they need to be.

The history of Git shows that Mr. Torvalds set about building the underlying file-system content model with the assumption that eventually a good front-end would be built.  In the end, the front-end was accreted into existence and is the one everyone uses today.  I often wonder how tolerant defenders of the Git command-line would be if they didn’t have StackOverflow when they were learning.

Perhaps somebody will provide an alternate front-end to the Git places model that fully acknowledges the places and the interactions as first-class citizens.  It might be a naive concept, but having a command-line that did something like
   git  --from INDEX --to REPO --interaction COMMIT

would at least match the underlying places model.  Obviously there are hundreds of subtleties I am overlooking, and I am sure such an effort has probably been done before™.

As someone in the comments below mentioned there is another beautiful site out there that focuses on the Branch Model.  I highly suggest you go to this link http://pcottle.github.io/learnGitBranching/ and see how utterly skilled people can be with javascript.  You can interactively explore the Commit DAG and see how rebases, merges, checkouts and resets work.
In my following post, I had put together a mini-animated gif to show something similar, but I think this site does a much better job.  

However, what neither my animated gif nor this site show is how most commands modify the models at the same time, e.g. how the Places Model is affected by such things as git reset with options like --soft, --hard, --merge, --mixed modifying your index and/or working directory. In fact, the subtleties involved in knowing that different types of git resets are not only modifying your Branch Model (where your HEAD-branch pointer resides) but simultaneously your Places Model, lead to a lot of confusion.  This StackOverflow answer is the one that I still refer to.

I think there is a place for a good visualization (animated or not) that shows how both models are affected by each type of git command at the same time


  1. The biggest problem for me to move from SVN to Git was absence of good git app (with good UI) to manage local resources and synchronize with remote sotrage. When I discovered Source Tree or Smart Git I want use git for all projects.

  2. The reason why SVN users find git so hard is because of the comparison that comes naturally to us. Which is what you have done in this post mostly. SVN is subversioning, so is git. They should not be that different? Right?

    Well, no. Because with git, there is an inherent change in the philosophy of subversioning. The whys, whats and hows changed. This is the reason why git exists in the first place. SVN does not provide what coders need. It is mostly used to share code with other devs, build servers. Try branching for a new feature and merging it back to the trunk. THAT is a pain in the ass. The wide acceptance of git by the dev community is a proof that git's philosophy won over SVN's.

    Most of the initial pangs SVN users face are because they are not used to the flexibility that git provides. It's like taking a slave and putting him in a free country. With SVN you could do only 5 things and there were 5 neat buttons in a flashy UI to do it. With git you can do a 100. There a local? There is a remote? What the heck is a stash? Those are the things that confuse you. But then why do you know about a stash if you don't have the need for it? Most of your problems are explained by your context. Since you don't need to code that frequently, git's powers are lost on you. Not so with someone who does a hundred commits a day. :)

    I suggest that any new git user approach git afresh and forget about SVN. That will make his/her life easier. Check out the first three chapters of http://git-scm.com/book . Also, don't explore a feature unless you need it.

    1. Personally I'm tired of learning whole new philosophies every time someone decides to build an app. I just want it to work. Perhaps I'm just impatient, but I am here to complete applications not prove how awesome my knowledge of "the force" is. In the first 10 years of programming that was important to me, but now I just want to complete projects and make some $.

    2. Yes - this guy

    3. +1

      I just want to get my work done. Do they think I would give priority to learning Git, over learning Spring or Hibernate or Hadoop?

      A good version control system should just do its job and get out of the way.

      BTW, whats with that easy branching with Git? Now there are local branches and remote branches? I dont think it is less complicated than SVN. I have never used SVN branching extensively, but I remember simply sending a request to the SVN admin to create a branch, and it was done in minutes !

      >>> Personally I'm tired of learning whole new philosophies every time someone decides to build an app

      Unless it is improving my productivity or letting me achieve something more. Is Git increasing my productivity or doing more than version control?

    4. +++++++++++++++++++ amen.

      All this new crap is by people who don't want to learn the old and they spend huge amounts of time reinventing the wheel rather than improving what's already there and it puts the rest of us through hell.

    5. This comment has been removed by the author.

    6. Yes sir, Git is made by a geek and its main audience seems to be geeks, not developers. It seems to care more about "showing the force inside the master" than being pragmatic and fulfilling requirements/needs.

    7. Finally someone with a brain! just get the job done, who cares how intellectually superior or inferior one source control over another. I don't understand all the fuss about it.

  3. For git branching, learn it here:

  4. The difficult thing about git for me is that I've seen so many "git workflow" blog posts, and yet I've never seen two people that have the same workflow. It's like Perl, there are a million ways to do something, which can make it difficult to learn.

  5. The best thing about git is that it keeps away the riffraff coders since it's so hard to learn. I propose that the next version of git is even more abstract, harder and shittier to use, so that only the most elite of programmers can use it. That way, the quality of open source software will skyrocket while the quantity of projects will dramatically drop, making it much easier to find what remains.

    1. Well I could laugh if I didn't have to cry. Maybe there are people writing software for many many years, who have seen VCS'en come and go. GIT is basically just another barrier to be productive. It makes you shift focus from programming to fooling around with an arcane and plain weird command line that just moves bits around on your disk. In other words, it does not add anything to your project, except much more storage and hassle.

      I agree that the underlying technology is fantastic and ideal for collabarating with many people but my God, the interface is horrible. Everytime I use it I feel like I'm polluting my internal namespaces, causing brain damage.
      So, while you're playing around with your new file-copying toy that has a lot of buttons, I'll be releasing my latest projects and meanwhile be on the lookout for better distributed VCS that has a sane interface. Thank you!

    2. Then you're doing it wrong.

      I've been at this for close on 2 decades, and git is one of the most industry changing tools to ever cross my path because it helps protect me from ... me.

      I'm one of the 99% developers who are sloppy, human and with a short attention span. It may have taken a little work to get my head around dvcs and git in particular but it's paid back in spades.

      If it's visual tools you want there are plenty of good ones now - TortoiseGit on Windows, SourceTree on Windows and Mac, and the one integrated into the JetBrains IDEs are all superb.

    3. No, he/she is thinking correctly. Git is a productivity killer. The mass cult-like worship of it stems from something endemic to the development world, that is, the ( often macho ) need to find tools that are difficult for the sake of being so. It introduces a cool factor because you spent every night and weekend learning the byzantine procedures and it makes you feel superior to the plebes. Meanwhile, us plebes are busy either working on useful things like, oh, our applications or enjoying some time out in the fresh air.

      Git is a powerful tool, but its flexibility is its fatal flaw. It is not well-structured in making the most important operations simple to use and being transparent to your main work. It requires far too much mental cycles for regular usage, the syntax is terrible, worrying about all these places where data is and what state its in, and how easy it is to get your data screwed up ( it happens far more than git lovers will every admit. I've had it lose files that were never recoverable several times this year alone ) and waste yet more time untangling the mess...

      Unfortunately, it's not the first time a bad solution has become the standard. We can only hope a better one will come along.

    4. Agreed it is awful, even comparing two versions of the same file together that are checked in is so painful.
      The best version control software I have used in the last 20 years is Starteam

    5. "Then you're doing it wrong." Someone take whoever wrote that comment above and nail them to a wooden post.
      A tool is supposed to help me do my job, and when it comes to source control it's also supposed to help confine a team to a manageable process. In both of these things, Git fails miserably.
      Git is a waste of time that fills one with uncertainty and dread whenever something goes wrong. And it does, all the f(((g time.
      Just the other day we discovered one external dev pushing from repo A to repo B, by physically copying his filesystem from folder A to folder B and forcing commits. No warnings, no complaint, nothing. No management. Why no management? Because GIT is not something management understand? Doing it wrong? Tell the f(((g management.

    6. Really I do not see why people find git so hard. Once I spent less than a week getting used to it, and knowing how to use its features, its been a complete non-issue for me. I don't even think about it while I am using it.

      Whats so hard about git pull, git branch, git merge etc?

    7. >> even comparing two versions of the same file together that are checked in is so painful.


      >> Whats so hard about git pull, git branch, git merge etc?

      at least it is much easier to merge your local changes and whats on the repo with SVN. With Git, I have three - working dir, local repo, and remote repo.

  6. Check out https://github.com/landobyte/glo Its a git addon we built and it works well.

  7. github is a complete waste of time...why spend your time working on a complicated system and a programmers ego which could have been used actually creating useful projects and programs!!!

    What a disgrace

  8. Untalented programmers like Git because they can spend their time mastering a ridiculous workflow instead of producing actual work, which they are unable to do.

  9. This comment has been removed by a blog administrator.

  10. I tell you a true story.
    For my personal solo project, i use GIT. I have no choice because OpenShift, Appfog, Visual Studio Online need it.

    However, on my workplace, I am a project lead of a team with 10 peoples (programmer and web designer).
    Day 1, every people agree using GIT, why?
    Because everyone is excite on GIT, which is a famous and brand new VCS. (on 2011)

    About 6 month, i hear some of them complain, they spend time to do commit/push/fetch/pull/rebase and resolve the conflict!

    So finally, i stay with SVN and everything more simple, commit and update ,done.

    1. We still use CVS because it is even easier to use, fully supported by almost every old and new IDE and it just works and it's easy to make backups of it or SVN to recover from anytime.

  11. the problem with GIT is that you AHVE TO learn A LOT of things before you can even USE IT
    whereas to SVN the common sense is enough to save you without actually learning online
    => anyone would understand a checkout or commit in SVN
    but in git .... no

    so it might be in the future a good tool but the command line is AWFUL
    not consistent, not explicit, and confusing

    example : a checkout or checkin ... anyone says ok i get it

    but in git you can't guess you HAVE TO KNOW a lot of tricks

    i do use and know git because of i am FORCED to use it at work...
    i would not advice it for a project though for the simple reason that developers , at least some
    are not comfortable to do simple things like checking it, out, diff...
    using command lines and bottom line is (whatever the reason could be)
    what takes 1 click in SVN takes 10 minutes and 5 thoughtfully crafted lines in git for a "non expert"
    which is most people ...

    so yes the model is more powerful but no don't use it yet
    wait for a good UI and MAYBE it ll be worthing it

    and i believe 95% of the time pole do not need distributed
    and a clear simple UI would be one hiding things such as the distributed layer of it...
    to fall back to a SVN like UI

  12. Before concluding that Git's complexity is warranted to solve the problem of distributed version control, check out Mercural and Bazaar. While Git is certainly faster than both of these, the others are orders of magnitude easier to use, approaching the ease of use of Subversion with all the benefits of distribution.

    I don't think lots of Git users have given these systems a serious try, or are so far embedded in Git thinking that they see all the shortcomings of Git as the "right" way to do things, regardless of the needless complexity involved. Complexity however is not Git's worst crime - the bigest problem with Git is that it gets the branching model completely wrong.

    See this older post about Mercurial named branches vs Git branches: http://jhw.dreamwidth.org/2049.html

    And this more recent post comparing git/hg/bzr branching: http://duckrowing.com/2013/12/26/bzr-init-a-bazaar-tutorial/

    With either Mercurial or Bazaar, you can get the benefits of DVCS without Git's headaches.

  13. Git is such a huge overhead. Never had any major problems with SVN Everything is lucid and folder based. All those message i see in git about rebasing, forced commit not allowed, pulling, push make me sick

  14. Finally some people not raving about how good GIT is.

    The progress of technology can be understood in terms of efficiency. If a new tool can make someone or something more efficient in some way then it will be successful and will stick around. This is why societies are tending towards becoming just-in-time with little redundancy if things go wrong. Redundancy equals cost. It also explains why jobs become increasingly specialised over time. You can have one person do one thing well to save others from having to do the job themselves.

    Seen in this way though you can start to understand the limitations of GIT. Sure it is faster at merging in changes in a massive open source coding project, but the cost is that the complexity increases for each contributor. They have to learn a more complicated version control system that can easily blow up the moment they do something slightly wrong. The larger your project the larger your net cost.

    A successful tool should make the user more efficient. It should make their job easier, not harder. Tools that achieve this allow people to do more than they otherwise could and be more productive.

    This is why we use cars instead of horses and computers instead of an abacus.

    Perhaps a future Git-like version control system will be developed that will be ideally suited for use by one person specialising in incorporating the updates from coders who can be freed up to concentrate solely on programming. Or maybe Git will eventually be developed to be intelligent enough to perform this role itself. But at the moment, it's not managing it. But this is the problem with clever tools. They are never as clever as a human being and more often than not cause more problems than they solve.

  15. Thanks to all who have confirmed that Git's concept of operation is indeed from some Bizzaro world. I've been using version control systems for a long time, and I thought that Clearcase had pride of place for convolution to confuse the enemy (its users.) At first, I'd assumed that my own struggle to learn Git was simply evidence of my own limitations - otherwise, how could something so wildly popular be so damn hard to understand? But I now recognize this is yet another example of horrible user-interface design that results when clever programmers who don't give a damn about usability create something completely idiosyncratic, or worse, gleefully use obfuscation as a secret handshake to screen out the unworthy.

  16. I do not like Git. It is too flexible and too complicated. So far, in our company, I have witnessed several serious complications and no benefits. The teams at our company would be benefiting from central, rigid source control with tight process. Despite all the Zen pics above, and pseudo-religious claptrap.

  17. KISS principle comes to mind! But not with Git.

  18. Some people ...admit that they are pissed using Git because it sucks out their brains more than any other VCS tool in the past. Git distracts them (not totally, but significantly more than other VCSs) from getting their “main work” done (http://scn.sap.com/people/martinkolb/blog/2015/04/02/proud-to-be-a-moron-my-journey-with-git#).

    And this is definitely true!

  19. We've just spent the past several months migrating the entirety of our source code, in several different programming languages and development stacks, from SVN to Git. Now, instead of allowing the developers to simply branch and merge file content as they're accustomed to doing, time and time again we have to sit down and: analyze why the merge process is doing something completely different than what we expect; figure out how to select the proper options in SourceTree and TortoiseGit to let developers stop trampling the code of other developers; analyze whether our branching and merging "mental model" is sufficient by comparing it to Git Flow, back-merges, fast-forward merges and rebasing, and merging using one of five different merge strategies; and then explaining that mental model, and the excess of command-line options that accompany it, to the developers in a way that they can understand it compared to the trivially simple "update" and "commit" operations that they want back from SVN. What a big win for us!

  20. I use git for 6 month now, I seriously question sanity of anybody who blobs about its flexibility or some other nonsense. Talk about philosophy of source control ? Seriously ? Here is the philosophy for you , brain-dead linuxoids, - I have 2 or more versions of the same file , I JUST WANT TO MERGE IT, not stage, not fucking pull or push, aply , unaply , pop , branch , reverse, hunk, JUST FUCKING MERGE

    1. I leave this post up as an example of what not to post. No ad-hominem (e.g. 'brain-dead linuxoids') and no cursing. This post feels like a punching bag to let out the rage. It has some relevant points: "I JUST WANT TO MERGE IT, not stage, not fucking pull or push, aply , unaply , pop , branch , reverse, hunk" which are useful to understanding the psychology of users from a UX standpoint,
      but mostly it is just anger.

    2. I support you 100% Anon! Forget about that Daniel guy :)

  21. This comment has been removed by a blog administrator.

    1. Your language is abusive and threatening. I am deleting your post.

  22. Ok. I calmed down. I can control my hands now. Ok. Calmed down.
    Charlatans don't have anything to sell, and keep selling you more and more complex stuff. This is typical of charlatans and untalented people. Genius is always simple. Charlatans are always complex. That is the bottom line of this whole story.

    1. There has been a recent trend here of people posting in these comments as a discovery of "git"-trauma survivors. My guess is that the title of my posting comes back as the result of an extreme moment of frustration when someone goes to Google and types: "Why the heck is X so Y?" (where X is the object of frustration and Y is the negative quality). Mostly, these people are looking to co-commiserate with 'survivors'.

      I do not share your disdain of Git, and find that these recent comments are a) echo-chamber complaining and b) short-sighted.

      I do NOT think GIT is the best thing ever, but the point of my post was not to complain about its architecture, but to highlight the very real complications of real-world usage and how its difficulty arrives naturally. This Anonymous post I am responding to is silly: "genius is simple". Real-world scenarios are never simple and doing source-control in complicated situations is bound to be difficult. Almost all of software engineering is a reflection of this.

      I leave all of these comments up because I think everybody can benefit from them, except the abusive posts with potty-mouth adjectives which are deleted -- they add nothing.

      The main truth I gather from these angry posts is that Git is probably an overkill for many simpler situations, and many simpler organizations. From this mismatch, of putting a trendy Git into an organization and situation that may not warrant it, comes these posts.

      Git is a full-fledged engine with dozens of levers and switches and an un-opaque underlying file-system. I too have to go to stackoverflow to do things outside of the normal, and I too have cursed it, but I think the many people who are posting here with their angry screeds are not realizing that being a programmer/software-engineer in a team (or even solo and with a desire to roll-back and maintain a history) requires having a rigorous set of skills around toolsets.

      I know it's tough already being a programmer/software-engineer and knowing your language, its libraries and frameworks, and text-editors and unix commands, etc etc. but nobody sad it would be easy.

      Simple works for simple scenarios.

  23. This comment has been removed by a blog administrator.

    1. like the post above, abusive language... i'll chalk it up to you having a bad day.

  24. For me it doesn't seem hard because it's different. It is hard because the complexity and layers are hidden. So many guides just give steps without clearly visualizing what exactly is happening in concrete terms. It's like teaching someone to write SQL queries without a way to visualize the structure of the database. Even graphical tools do a poor job of giving one access to all the different layers.

    The nuanced behavior of Git is exemplified in the many guides that cover using git pull, contradicted by the many recommendations to never use git pull and instead do a fetch+merge(which is what pull is *supposed* to do, but for many valid reasons you shouldn't use git pull). What you end up doing instead is a deterministic workflow, so we end up doing something that a computer could do for us. IMO, that's a clear loss in productivity.

    That doesn't mean Git is a bad tool though. Git was created out of necessity to address certain usage scenarios that *primarily* apply to open source projects, and in turn requires these layers and complexity to accomplish certain goals. For example, being able to submit/review/accept a commit from a non-privileged user. I.e. someone without direct commit permissions. The ways to accomplish this in other VCS are by comparison fairly archaic. (Of course there are a couple other distributed tools that accomplish the same, but are also similarly complex).

    So certain usage scenarios make Git or a similar distributed VCS necessary. If I'm not doing open source development, I won't use Git. When people start talking about being able to have your own local branch, most products provide features that give you similar benefits with less complexity.

    For example, you have to be very careful about how update your fork from upstream to ensure your changes layer into the history correctly. When I bring new developers onto a project, I need to focus on getting them up to speed on the project itself, not the nuances of the VCS that they may not be familiar with. Not understanding all of these nuances goes beyond just a productivity issue, and can result in bad commits that either lose work or result in bad merges. I don't want that risk. I want to be able to include entry level developers on projects, and have them focus on the code, not on the VCS.

  25. So much git-hate. I can understand.

    Just use Mercurial instead. It's get all the power of git without the stupid command-line interface and rubbish documentation. The Mercurial devs actually care about making their tool easy for newcomers. See hginit.com

  26. This comment has been removed by the author.

  27. As someone who is thinking about transitioning from SVN to GIT, compared to SVN I find GIT not difficult but inefficient in terms of steps a programmer needs to make in order to complete a simple task.

    Here's a drawing comparing the two: https://goo.gl/GLDGFZ

    I do understand the benefits of such a VCS system for large or distributed teams and open-source projects, since it protects the central repository from uncontrolled changes.

    However I don't think it's well suited for small teams (especially if you're working alone). In such scenarios all the pulling and pushing, needed to keep your local repo in sync with the central repo, is just extra work, which isn't adding any value to the product you're working on.

    In addition don't like the idea of having a local repo, since the HDD failure means the loss of all the changes which weren't pushed to the central repo. Commiting to the central repo has the benefit of easy backup. If your dev machine dies, all your work is still stored in the repo + a backup server.

    After studying a few GIT branching workflows I concluded that most of them can be implemented in SVN with almost no effort.

    I'll invest some more time in exploring GIT before I make my final decision if I'll switch from SVN. For now I don't see any benefits from switching to GIT (except maybe staying in the loop with most popular tools).

    One thing I do like about GIT is the concept of rebase. I'm yet to see how this procedure handles conflicts which might emerge.

  28. Team Foudnation Server will do everything that Git does, but it's easy to use. The only thing that's hard in TFS is creating a trunk if you accidentally put your initial commit in the root of the bound folder. But that's not really that hard to sort out.