Branches aren't effortless IMO. And every programming productivity book written in the ten years agrees. Branches lead to lots of extra work and many new bugs when you come to merge them. The longer the branch lives the worse this gets.
-
-
Replying to @StevenBHutton @meglio
If you have a release coming up you will likely have many features all being merged from various branches. You then need ANOTHER branch for release stabilisation, to merge everything to just to handle the chaos. I want to release after every commit, not after weeks of prep...
1 reply 1 retweet 6 likes -
Replying to @StevenBHutton
How well does this approach scale? Examples?
2 replies 0 retweets 0 likes -
-
Replying to @StevenBHutton
May I also ask
@cmuratori and@Jonathan_Blow if you use branching in git/svn? Why/why not?2 replies 0 retweets 2 likes -
We don't use branches. I try even to discourage programmers from running de facto branches, where they are making a big change that they don't check in for a long time, because that tends to slow things down and introduce problems. Almost all major changes can be made
3 replies 2 retweets 39 likes -
Replying to @Jonathan_Blow @meglio and
incrementally, and this doesn't cost extra in terms of planning etc, because you get contact with the reality of the rest of the system sooner, and spot problems sooner. Not the same as branching but related, the #1 way that builds break is when someone has a bunch of changes
3 replies 0 retweets 24 likes -
Replying to @Jonathan_Blow @meglio and
and does a partial check-in. Very easy to forget some overlap between what you think are N independent changes. I encourage people to check in 100% every time.
1 reply 0 retweets 21 likes -
Replying to @Jonathan_Blow @meglio and
Some of what I have said above may be a function of team size (we have few programmers). In a bigger team we would probably have to do some stuff differently, but I doubt my preferred approach would match what you see commonly.
2 replies 0 retweets 9 likes -
Replying to @Jonathan_Blow @meglio and
Re Steven's point about the cost of branching, I would say that the whole idea of branching assumes you are in an environment where productivity is low relative to the size of the code base. As productivity rises, branches make increasingly less sense.
4 replies 0 retweets 16 likes
I would also add that people routinely underestimate productivity lost due to time spent working with source code control systems. If an SCCS saves you ten minutes while costing you an hour, that was not a win.
-
-
Yep.
1 reply 0 retweets 2 likes -
Replying to @Jonathan_Blow @cmuratori and
Actually I'll keep going ... branches assume that you're only changing code. But the more important your change is, the more likely it is to have an impact on data, globally, and if that data is stuff people are working on, it may be very unlikely that you could merge it well.
2 replies 1 retweet 12 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.