I have used Git and Mercurial a bit over the past ten years and appreciate and prefer them, but most of my experience is with SVN. If it is decided within a corporate programming group that branching and merging are not to be done because they cause too many problems then what significant benefit remains for Git over SVN? I am aware that offline and local abilities are beneficial but it seems to me that their benefits are minimized by the banning of branching techniques and the minimal amount of time spent working offline.

I prefer Git and am not looking to argue against it but it has been said to me that Git would make things better even though we should not branch and merge.

closed as primarily opinion-based by gnat, Robert Harvey, Bart van Ingen Schenau, GlenH7, Scant Roger Dec 11 '15 at 23:11

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    If your team doesn't want to branch and merge, then you shouldn't be using Git, as branching and merging is the correct way to do things in Git. Merging changes into the production branch directly is just too difficult and causes its own problems. – Robert Harvey Dec 11 '15 at 18:31
  • 3
    Don't discount the advantage of committing locally. Git branching is great and all but committing locally is huge too. In my experience committing locally with Git is still orders of magnitude faster than committing to SVN so it's easier to more frequently commit your changes. When your work is ready, you push it up. While I personally wouldn't recommend it everyone can commit to one branch locally until their work is done, then pull down the latest changes. You might have a merge conflict, but you'd have that anyway in SVN and Git's merging is leaps and bounds better than SVN's. – Ryan Taylor Dec 11 '15 at 18:33
  • 2
    @altendky: It's not branching and merging that's bad, per se; it's merging. If two people are working on the same class at the same time, merging is going to be a pain in the ass whether you branch or not. Branching merely allows you to isolate your work from the main branch for awhile. In our shop, we are currently moving away from single commits to a branch/rebase strategy similar to the one everyone uses on Github using pull requests, and nobody works remotely here. – Robert Harvey Dec 11 '15 at 18:37
  • 2
    @altendky Commits aren't branches. No matter what you do, if you have multiple people working in a repo (SVN or Git) you will have commits. You will have merges. And you will have merge conflicts. This is unavoidable. Whether or not you choose to use branches up to your development team. – Ryan Taylor Dec 11 '15 at 18:41
  • 2
    @MasonWheeler You're clearly unaware of how distributed version control works. I regularly use Git to create local repositories of small projects. I don't use it for backups, and I don't keep remote copies of some repositories. The point of source control is to control your source code. It has nothing to do with remote backups or "getting work off of your local system and onto a specialized server". You're imaginary distinction between "local commits" and "real commits" shows your ignorance. – nanny Dec 11 '15 at 20:47

It's beneficial because the entire company doesn't have to use the same policy. You can have an official no branch policy on the official central repo for the branch-averse people, but small local teams can pull from each other, commit frequently, and set their own policies, as long as they adhere to the policies when they push to the official central repo.

I actually use git on top of perforce, so I can commit locally much more frequently between perforce commits, which provides a lot of freedom to experiment, while being able to easily back out debugging changes from the last 10 minutes or so. I can quickly create a local branch to fix a bug, then return to my long-term task. There are a lot of benefits to using git without long-term branches, even locally without the official approval of the company.

  • I agree that being able to locally ignore the 'policy' is beneficial, albeit a bit sly. :] – altendky Dec 11 '15 at 21:49

Taking the SVN model, you are going to have N+1 branches for every N developers modifying the head branch. This gets more complicated once you factor that eventually these branches do not share the same common ancestor (i.e. modification was started from a different commit).

So, even if you only publish a single branch, your tool must support merging and conflicts. Git lets you support branches with a model that handles these simple cases, plus things much more complicated. The benefit for the user is that once you understand this model, it can be applied to the complex actions while keeping the fundamental process the same.

For example, you could create an unlimited number of branches in your local repo that can be merged, modified, re-ordered, adjusted, etc. The commands for handling these operations are the same as if you were working with branches created by others.

Assume though, that your project is just 1 developer who always commits to the master branch (i.e. there is truly a single branch), the architecture of git is far superior to SVN in a number of fundamental ways.

  1. The SHA1 hash of your branch validates the integrity of the entire branch. If any file or commit message is modified, the SHA1 value would change. This guarantees that you will immediately detect corruption of your repo data.

  2. The git repo is self-contain and does not require a server or any configuration. You literally can create a new repo in under 1 second.

  3. Git keeps all your revisions in your local repo. This makes running search and diff commands between changes orders of magnitudes faster than SVN. Imagine finding the commit that changed a line out of 10,000 changes, or finding any change that contained a global variable in code base with 50,000 files or more. Git can return results in seconds when running on ubiquitous SDD drives.

  4. Git tracks content not files. This gives it amazing abilities to easily track files that were renamed or blocks of code that moves between files. Some tools like SVN support renames, but git does this without you having to tell it there was a rename.

  5. Git makes it easier to create a commit that implements a "single logical change". This is important for reading your commit history and when you need to revert specific commits that were later found to either need additional work or become obsolete. SVN will only let you submit a single file at a time, but coding doesn't always happen linearly and sometimes if you forget to submit each change, you'll eventually collect 3 or 4 separate changes in the same file. Git makes it easy to create 4 commits from 4 changes in the same file (however if the changes overlap, you still have to recreate the intermediate states that were lost)

  • Your five points are pretty directly on-topic, thanks. I don't think they would make much of a difference in the case of my team, but I do agree they are valuable. On 5, I would point out that TortoiseSVN does have 'revert after commit' which provides kind of stash-like functionality or hunk-selection commits, mostly as an FYI and it is admittedly not part of SVN proper. – altendky Dec 11 '15 at 21:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.