-2

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.

altendky
  • 207
  • 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
  • @gnat Thank you for the link and I agree. I am trying to think through how to clarify this question but am having difficulty so far I am looking for feedback on scenarios I haven't thought of where features I am not considering or aware of become significantly useful. – altendky Dec 11 '15 at 18:33
  • @RyanTaylor I only discount the local/offline advantage within the context of a decision having been made that branching and merging is bad combined with my perspective that local/offline commits are basically small branches (bigger than single commits but smaller than feature branches). – altendky Dec 11 '15 at 18:35
  • 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
  • 1
    Not posting as a full answer but you might find this question and answer helpful. http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-should-i-consider-or-not-consider-mercurial-or-git-or – Ryan Taylor Dec 11 '15 at 18:43
  • @Robert Harvey I believe that branching implies merging unless you are not really branching but rather forking. I like feature branches and think that the associated understanding and skills help you weigh the benefits and costs in each particular scenario. – altendky Dec 11 '15 at 18:44
  • @altendky My point is that you will still have to merge, even if you don't branch, and it is the merging that is the pain point, not the branching. – Robert Harvey Dec 11 '15 at 18:46
  • @RobertHarvey I agree. Once we accept that merging must always occur (as I believe the three of us here do) the variation is in how many changes are being merged and how much interaction those changes have with each other. This can grow into merging hell with either Git or SVN when either number of changes or conflict of changes grow. But, I am looking for benefits of Git assuming we have decided (against my judgement) that branching shouldn't be done. – altendky Dec 11 '15 at 18:58
  • 1
    An alternate expression of the question title: "If process X is painful with tool A, then is there any point in tool B?" – Daenyth Dec 11 '15 at 19:00
  • @Daenyth I said "If process X is painful, then is there any point in tool B over tool A?" The claim is that the process is inherently painful. – altendky Dec 11 '15 at 19:04
  • @altendky I disagree that the process in inherently painful. I've worked on teams with multiple people committing to the same codebase, and with a small amount of discipline, it's not hard to avoid merge conflicts - and at minimum it's very possible to keep the responsibility of resolving conflicts to just the person who creates them. – Daenyth Dec 11 '15 at 19:17
  • @Daenyth "The claim" is not my claim. I like feature branches. A coworker has told me that branching and merging are so hazardous that we shouldn't do them and also has told me that switching to Git would be way better. I have turned to the community here for insight since my discussions with this coworker have not led me to understand the remaining benefits of Git if you ban branching and merging (which I think would be a bad choice). Regardless of the branching and merging question I presume that there are still benefits to Git that I am not aware of and would like to learn. – altendky Dec 11 '15 at 19:30
  • Let us continue this discussion in chat. – altendky Dec 11 '15 at 19:43
  • @RyanTaylor "In my experience committing locally with Git is still orders of magnitude faster than committing to SVN." Yeah, that's because it's not a commit; it's a local operation. It's still on your hard drive, and if your hard drive dies you still lose all that work, just as if you hadn't been using source control at all, because you didn't actually commit it. That's the entire point of using source control: getting your work off of your local system and onto a specialized server that's designed to manage it well. "Local commits" just make the process more complicated for no benefit. – Mason Wheeler Dec 11 '15 at 19:56
  • @RyanTaylor: Also, "Git's merging is leaps and bounds better than SVN's." Are people seriously still saying that? That used to be true many years ago, but it's been a long time since that was a valid claim and I doubt anyone's still using a version of SVN that old. – Mason Wheeler Dec 11 '15 at 20:06
  • 1
    @MasonWheeler "That's the entire point of using source control: getting your work off of your local system and onto a specialized server that's designed to manage it well. "Local commits" just make the process more complicated for no benefit." This is completely, utterly, and laughably wrong. – nanny Dec 11 '15 at 20:12
  • @nanny: Mind clarifying? Everything I said is a simple, self-evident fact. The point of source control is to create an independent repository that keeps a backup with version history of your project. Local commits don't contribute to the repository. Systems that use local commits make real commits more complicated because what would be a one-step process without them is now a multi-step process. There's nothing wrong there, let alone "completely, utterly and laughably" so. – Mason Wheeler Dec 11 '15 at 20:24
  • 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
  • @nanny I could just as easily say that your failure to comprehend the distinction shows yours, but I'm trying to argue on facts, not childish insults. If your source code only exists on one machine, then you're at risk of losing everything if you lose that one machine. This is a simple fact, and making another copy of it on that same machine and calling it a "commit" doesn't change that. I'm well aware of how DVCS works; I've been using it for years, including at my current job. It's a major irritation: pushing changes is a 3-step process at minimum, where it's only one step on SVN. – Mason Wheeler Dec 11 '15 at 20:52
  • 1
    @MasonWheeler git commit is a real commit, even if you don't push it. I'm not insulting you at all: you're just very wrong and clearly ignorant. "If your source code only exists on one machine, then you're at risk of losing everything if you lose that one machine. This is a simple fact, and making another copy of it on that same machine and calling it a "commit" doesn't change that." Obviously correct, but source control and backups are not the same thing, that's the point i'm trying to make. If a Subversion server goes down, you've lost all history. You need backups for both git and svn – nanny Dec 11 '15 at 21:01
  • @MasonWheeler Just because it's local doesn't mean it's not a commit. – nanny Dec 11 '15 at 21:04
  • @MasonWheeler "It's a major irritation: pushing changes is a 3-step process at minimum, where it's only one step on SVN." Here you've changed the topic from "committing" to "pushing", but i'll address it anyway: git commit -a and hg commit are both one step commits. Obviously, pushing is another step, but you can easily add a post commit hook if you want to do it automatically. But, you'll lose the benefits of dvcs. – nanny Dec 11 '15 at 21:08
  • @nanny: You keep making that assertion, with nothing to support it. I'm saying that yes, that does by definition make it not a real commit, because a commit is necessarily a non-local thing, moving your work to a remote repository, because if it's not moved to a remote repository then you don't get the benefit of a commit: having your work backed up to a remote repository where you can't easily lose it. If you want to demonstrate a flaw in my logic, demonstrate it, but saying "no, you're wrong and you're soooooo ignorant" is not a demonstration. – Mason Wheeler Dec 11 '15 at 21:09
  • 1
    @MasonWheeler "because a commit is necessarily a non-local thing" Why do you think this? This is the flaw in your logic. – nanny Dec 11 '15 at 21:10
  • @nanny Committing vs. pushing is a distinction without a difference, and artificially creating such a difference in DVCS is not a "benefit"; it's an irritation that does nothing useful in return for making your job more complicated. – Mason Wheeler Dec 11 '15 at 21:11
  • @MasonWheeler There is no "artificial" difference! The difference is clearly concrete: git commit -am "msg". That's a commit. Wikipedia says, "To commit is to write or merge the changes made in the working copy back to the repository." With git, your repository is on your local machine. When you git commit, you are writing the changes made in the working copy back to that local repository. How is that not a commit? – nanny Dec 11 '15 at 21:14
  • Comments are not for extended discussion; this conversation has been moved to chat. – yannis Dec 11 '15 at 21:14

2 Answers2

6

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.

Karl Bielefeldt
  • 147,435
3

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)

cmcginty
  • 729
  • 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