
Branches: Everyone Should Use Them - ColinWright
http://tomb.io/posts/branches-everyone-should-use-them/
======
mseebach
Everyone should stop making sweeping statements about what everyone should do.

Snark aside,

> _Long running branches are bound to happen, [...] Good communication comes
> in handy here if you are working on long running feature branches._

How about this: Instead of having long running branches, _don't_ have long
running branches. Everyone runs on the same master branch, and master is
always deployable. This way you don't need to communicate (yes you do, but the
sort of communication alluded to is secondary, the full, up-to-date code with
tests is the authoritative source). Have features that you can turn on and off
in configuration, it's not like having branches ensure that you didn't screw
anything up.

~~~
jacobr
Do you not even use local branches?

I recently evaluated different CSS-preprocessors for one of our projects. This
included not only changing and renaming a bunch of CSS-files, but also adding
new dependencies, updating Makefiles, etc. We ended up going with the first
one we tried, but it was a tough call so we might've wanted to revert it
completely. Isn't this a perfect use case for a branch?

We had previous experience with the preprocessors, but they behaved
differently used in our context with modularized CSS, lots of imports, using
our custom watch script, etc, so we had to try them out in the actual project.

~~~
mseebach
Branches certainly have their place, I'm talking about long-running branches.

------
CJefferson
The biggest problem I have with branches in git is that there does not seem to
be a simple way to delete a branch in a version controlled way.

For me, the whole point of version control is to be able to go back and look
at what I did earlier. The idea of doing destructive deletes of branches is
madness. However, if you don't, you end up in the situation I have now, where
my project has over a hundred branches, most of them minor changes or attempts
at things that didn't pan out.

The overhead this causes (including, just scrolling through the list of
branches) now makes me less eager to branch in new projects I work on. In svn,
I would just do 'svn rm branches/stupid-idea' and it would be gone, but still
exist in the history if I ever wanted it.

~~~
rudd
You can always replace the branches with tags (git tag failed-branch-mybranch
mybranch && git branch -D mybranch). That way, you still will have access to
the unmerged commits later, but your list of branches is clean. Your tags will
bloat up, but I personally don't go through my tags nearly as often as my
branches.

------
bergie
Some, like the authors of Continuous Delivery
(<http://continuousdelivery.com/>) seem to be arguing against branches, and
for a single codebase that is continuously tested, integrated, and releasable.

That said, private branches can make it easier for people to commit early and
often, as all changes can easily be squished together so others don't have to
see every "embarrassing" iteration.

~~~
ryanbrunner
Utilizing branches heavily does not imply that you shouldn't have a single
mainline branch that branches are merged down to often. In fact, it's
incredibly difficult to do continuous integration and deployment effectively
without branching. Continous delivery requires that your mainline codebase is
pristine and ready to be deployed immediately. Without the ability to make
commits that don't affect that mainline, that's an unrealistic expectation.

I would say the authors probably have an issue with long-running branches,
especially where communication between the mainline and the branch is sparse,
but short-lived branches have a ton of benefits if you're deploying
continuously.

------
skrebbel
My (8 person) team is currently developing software for a machine. It's the
first version, in fact the machine hardware doesn't even exist yet.

Instantly deployable code is, therefore, of no interest to us (currently).
Things'll be different when we have releases out, installed in machines at
customers, but for now, really, why branch? The author does not actually give
any other argument for branching, except for "master should be instantly
deployable". And even that problem could be solved in other ways than e.g.
feature branches.

In fact, we want to take continuous integration to extremes. This means that
if I work on X and George over there works on Y, and we end up breaking each
other's code, I want to find out as fast as possible. Not when my feature is
done. Today.

Less branching directly implies earlier feedback. We've yet got to hit the
problem that people are really messing in the same code, big time, at the same
time - after all, that's what the daily standup is for, right?

Really, how would branches help us in any way?

~~~
dwc
Branches are a method for organization. I organize papers by putting them in a
stack on my desk. If the stack gets too big I throw them in a box, intending
to go through them later. But of course I never do. This is obviously a
_horrible_ scheme, but I get by just fine because the volume of truly
important papers I deal with is small. It surely wouldn't scale. Even so, more
orderly people are probably cringing as they read the above, and to some
degree they're right.

But I write code for a living, and I spend more time cleaning up my file
system, organizing source code, et al. I do this because I know that _not_
doing this ends up as more work than doing it. I use branches so that when I'm
in the middle of implementing a feature and a user comes to me with a bug
report I do not have to sweat having half refactored, half implemented,
uncompilable stuff. I can switch branches and work on the bug. Ditto for
interfacing with other devs working in other parts of the code.

Finally, I have to wonder if you've used branches enough to get a feel for
what they can do for you. I know that using CVS and Subversion I avoided
branching as a scary and tricky thing. Having them work so easily in Git I
began branching and found that it changed my workflow for the better in a
fairly painless way.

------
Toenex
Unlike centralized version control, DVC systems also have another available
topology namely separate repositories. I guess some teams may rethink their
branching strategy once they experiment with multiple repository topologies.

------
j_col
I'd much rather see people making better use of tags. I inherited a git-based
project recently where branches were being used as a sudo-tag to indicate what
code was currently deployed to each server environment, but no tagging of
releases whatsoever :-(

~~~
tombell
Tagging is useful for libraries and such. But for web sites and the like, you
can just use the deployed commit SHA as an identifier. Much like GitHub does
<https://github.com/site/sha>

