Hacker News new | past | comments | ask | show | jobs | submit login
Developing on HEAD scales to Google (bentilly.blogspot.com)
26 points by btilly on Feb 5, 2010 | hide | past | favorite | 13 comments



> 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.


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.


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.


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.


All the more reason to get your feature done first, am I right?


When that happens, I usually rebase on top of both master and the other guy branch.


By the time you've noticed that it happened, it is too late to avoid trouble.

Furthermore many organizations set up and organize branching in such a way that you have no option to freely define your branch like that. For example in the Microsoft story I linked to there is a multi-level merge process. If you just merge from a random other branch, then multiple merges later when code from your branch is officially merged with the other branch you'll have caused a nightmare because you've got an old and buggy copy of all of the changes in that other branch. The people whose job it is to sort it out will want to kill you. Particularly if you've merged in code that was explicitly discarded from the other branch.


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.


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...


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.


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.


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.


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.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: