4 ms·

> only one branch is going to be the actual product and the other branches are wasted effort. Not necessarily. Where I work, the primary software development

> only one branch is going to be the actual product and the other branches are wasted effort. Not necessarily. Where I work, the primary software development happens on embedded telecom hardware, which is then supported for years and years later. We have many different current and legacy versions of the same codebase that are still in various stages of development, production, sales, and supprot. On top of that, there are multiple releases of each version for various types of customers. Now granted, we don't use Git (or any sort of modern VCS/DVCS), but the need for branching is very real and does not always stem from whimsical developers. There are plenty of real-world scenarios where intelligent branching is a huge benefit. Another situation I know of is the Mantis Bug Tracker project that I work on. We just recently switched from Subversion to Git, and we have three primary branches in our repository for the old-stable, current-stable, and development versions of MantisBT. We use Git's branching to allow us to work on large changes to the legacy codebase without disrupting the stability of the development branch, and Git allows changes from one branch to be very easily ported to parallel or older branches. "Herding cats" seems like an indirect substitution for "I don't like branches so no-one should use them."

tptacek 18y ago
On the large commercial projects I've worked on, technology hasn't really been the problem with branching; even if you make branch-and-merge seamless, which nothing does, you still have to approve changes. That's harder to do with personal and ad-hoc branches, because there's no assurance that any planning went into the changes.
- rmaccloy 18y ago
  It's exactly the opposite in my experience: people will either commit untested junk to whatever the working tree is (usually trunk) or keep a bunch of untested code unversioned in their working copy and hopefully get it checked in at some point. Git moves the 'good enough?' check from commit time- which a) is harder to perform (since the codebase is changing under you) and b) forces a context switch - to merge/pull-from-developers time (which is much, much easier to manage with git.) DVCS is basically a partial technological solution to a problem (change control) formerly solved by process- interaction between the change control authority and developers. With DVCS the change control authority can avoid having to interrupt development workflow as much, which is a good thing.
  - tptacek 18y ago
    Without arguing the point, can you explain why merge is much, much easier with git? I just want to hear what things you bring up. I like git, and use it, but I'll be honest and say the only thing "killer" about it for me is github.
    - jrockway 18y ago
      Without arguing the point, can you explain why merge is much, much easier with git? I just want to hear what things you bring up. Have you tried it? It just works more often than an svn merge. There are a variety of reasons for that. Git records more data about where the branch originated from, when it's been merged previously, etc. That makes it easier to merge successfully, without conflicts. Sometimes things just conflict, though, and Git can't do anything about that. Git makes it very easy to get to an un-conflicted state quickly, though, even if it means forgetting the merge all together. svn is slightly less leniant, and if you say "merge", your only options are to fix the conflicts, commit the conflicted files (and be murdered by your coworkers), or throw away your working copy. Not fun. So to answer your question -- merges no longer cause pain. They either Just Work, or you can revert them easily.
      - timr 18y ago
        "Have you tried it? It just works more often than an svn merge." I use it every day, and don't find this to be true. I have to resolve conflicts at about the same rate as I did with Subversion. "Git makes it very easy to get to an un-conflicted state quickly, though, even if it means forgetting the merge all together. svn is slightly less leniant, and if you say "merge", your only options are to fix the conflicts, commit the conflicted files (and be murdered by your coworkers), or throw away your working copy. Not fun." Don't be silly. When it comes to conflicts, you can either resolve them, or throw the merge away. Git is no different than Subversion in this regard.
        jrockway 18y ago
        How do you throw them away in svn? If you have changes in your working copy, you can't throw the merge away without throwing those away. Hence the pain.

tptacek 18y ago

On the large commercial projects I've worked on, technology hasn't really been the problem with branching; even if you make branch-and-merge seamless, which nothing does, you still have to approve changes. That's harder to do with personal and ad-hoc branches, because there's no assurance that any planning went into the changes.

rmaccloy 18y ago
It's exactly the opposite in my experience: people will either commit untested junk to whatever the working tree is (usually trunk) or keep a bunch of untested code unversioned in their working copy and hopefully get it checked in at some point. Git moves the 'good enough?' check from commit time- which a) is harder to perform (since the codebase is changing under you) and b) forces a context switch - to merge/pull-from-developers time (which is much, much easier to manage with git.) DVCS is basically a partial technological solution to a problem (change control) formerly solved by process- interaction between the change control authority and developers. With DVCS the change control authority can avoid having to interrupt development workflow as much, which is a good thing.
- tptacek 18y ago
  Without arguing the point, can you explain why merge is much, much easier with git? I just want to hear what things you bring up. I like git, and use it, but I'll be honest and say the only thing "killer" about it for me is github.
  - jrockway 18y ago
    Without arguing the point, can you explain why merge is much, much easier with git? I just want to hear what things you bring up. Have you tried it? It just works more often than an svn merge. There are a variety of reasons for that. Git records more data about where the branch originated from, when it's been merged previously, etc. That makes it easier to merge successfully, without conflicts. Sometimes things just conflict, though, and Git can't do anything about that. Git makes it very easy to get to an un-conflicted state quickly, though, even if it means forgetting the merge all together. svn is slightly less leniant, and if you say "merge", your only options are to fix the conflicts, commit the conflicted files (and be murdered by your coworkers), or throw away your working copy. Not fun. So to answer your question -- merges no longer cause pain. They either Just Work, or you can revert them easily.
    - timr 18y ago
      "Have you tried it? It just works more often than an svn merge." I use it every day, and don't find this to be true. I have to resolve conflicts at about the same rate as I did with Subversion. "Git makes it very easy to get to an un-conflicted state quickly, though, even if it means forgetting the merge all together. svn is slightly less leniant, and if you say "merge", your only options are to fix the conflicts, commit the conflicted files (and be murdered by your coworkers), or throw away your working copy. Not fun." Don't be silly. When it comes to conflicts, you can either resolve them, or throw the merge away. Git is no different than Subversion in this regard.
      - jrockway 18y ago
        How do you throw them away in svn? If you have changes in your working copy, you can't throw the merge away without throwing those away. Hence the pain.