

Developing on HEAD scales to Google - btilly
http://bentilly.blogspot.com/2010/02/developing-on-head-scales-to-google.html

======
freetard
> The primary argument against branching is the pain of merging later

Except that when I work on a feature branch on git, I constantly rebase on top
of master to stay up to date and so I don't have to face a huge merge "later"
but a few easy merges once in a while.

~~~
btilly
That is a known best practice.

The problem comes when two people are developing stuff in two branches that
conflicts. When the first merges in, the second now faces the huge painful
merge.

~~~
ajross
Well, yeah. But that's not because of technology choice or development
methodology, it's because simultaneous work by two developers on the same
lines of code is _fundamentally a really hard problem_. It was hard before
source control, it was hard with SCCS and RCS, and it's hard with git.

No matter which way you slice it, one of the two developers (maybe both) needs
to sit down and figure out what the others' changes do and how they interact
with his/her own. That's a wetware problem, not something you can fix with a
tool.

~~~
btilly
That's true. But if both developers are developing out of the same branch, and
are checking in small patches at a time, they are more likely to notice the
interaction as it is happening and actually talk to each other.

The more difficult problems come when each worked on it for 2 weeks, then they
discover a month or two later that there is a conflict - after both have
forgotten what they were doing and why they were doing it.

------
axod
This is the only way I can work. I think it really keeps things clean+tidy and
forces everyone to make sure the current HEAD is clean, works and compiles.

Branching just isn't a natural workflow for me.

------
kylemathews
Sounds like continuous integration to me --
<http://martinfowler.com/articles/continuousIntegration.html>

Which is how I prefer to code.

Edit: "Work in Small Batches" is another great post on the subject by Eric
Ries [http://www.startuplessonslearned.com/2009/02/work-in-
small-b...](http://www.startuplessonslearned.com/2009/02/work-in-small-
batches.html)

------
brown9-2
The author doesn't seem to realize that working out of HEAD at Google might
only "scale" so well because of the rigorous code review process. Without, I
don't think it would be as possible.

~~~
nopal
I'm not sure how you reached this conclusion.

The author writes, "Guido's talk describes many elements of what makes it
scale...The second piece is an enforced policy of having every single patch go
through a code review process before you check anything in...And beyond that
you have people paying attention to best practices such as consistent style,
good unit testing, so on and so forth. (All of which are reinforced in the
code review process.)"

I think he makes it clear that the reason developing from HEAD has worked at
Google is because they have lots of processes to ensure success.

~~~
btilly
Exactly. There is an entire package of tools and development process which,
combined, makes things work out. The fact that you need an entire package, and
the difficulty of adopting multiple simultaneous changes to change how you
work is one of the primary reasons that I do not recommend that organizations
all rush out and adopt Google's strategy. There really is an all or nothing
thing here.

As an illustration of the dragons that wait, what happens if someone adopts
all of the tools and practices, _but_ the product manager is still able to put
real schedule pressure on developers. I guarantee that in the rush to finish
features that anyone who holds up implementation with, "This code is crap and
there is no way I'm approving it" will come under pressure to accept the crap
code. And as soon as you cross that line, the entire strategy falls apart
because, even though in theory you're following a good process, in practice
you just lost a critical underpinning.

------
vannevar
I've always thought the branch/no branch argument rested on a false dichotomy.
How is an uncommitted patch in any way distinguishable from a branch? One
could easily envision a case where it was easier to merge a branch than to
merge a patch where two programmers are simultaneously working on the same
HEAD code. Any working copy of the code is in effect a branch.

