Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trunk-Based Development

trunkbaseddevelopment.com

Post reply on HN
Print view View original

201–210 of 210 posts

Re: Trunk-Based Development

#201

Post by UK-AL »

sydd wrote: post #152
whack wrote: post #145

Earlier quoted context omitted.

> "This is specifically useful if your working on multiple releases at the same time. With git-flow, your pull requests ade blocked for the later release until the earlier release goes out of the door. When you later merge the PRs that has to go into the later release, you get massive conflicts which waste time." If you're doing git-flow right, your PRs shouldn't be blocked at any time. You should have a dev branch,…

But if feature branches can live less than a day then why not get rid of them altogether? They are just extra bueurocracy that just slow you down.

I would imagine there is a lot tooling around feature branches which are useful, such as code reviews tools, branch builds etc.

Re: Trunk-Based Development

#202

Post by paul_h »

cwills wrote: post #191

We have a smallish team working on web apps and use a trunk-based-development branching strategy. Not really to do with helping CI/CD. The advantage we see is that new developers can start developing as soon as they clone the repository, without needing to switch to the 'development' branch. This is particularly useful when on boarding new developers who are inexperienced with Git. I found that when using Git Flow th…

I looked at your diagram. I don;t think you're doing trunk based development.

Re: Trunk-Based Development

#203

Post by lucideer »

z3t4 wrote: post #133

I read Drunk-Based Development and was a bit disappointed. I can get awesome ideas while very tired and usually write them down, but a few weeks later, even though I was super exited when I wrote it down, it no longer makes any sense ...

I read Trump-Based Development...

Re: Trunk-Based Development

#204

Post by angry_octet »

brianwawok wrote: post #93
crdoconnor wrote: post #88

Earlier quoted context omitted.

I would hesitate to proscribe a "one true way" as well but the longer I develop the more convinced I am that a having branch lives longer than a few days indicates a serious underlying problem (usually a lack of test coverage or faith in said tests).

How do you support a 3 year LTS branch for enterprise customers without long lived branches?

OP: this works for Google and Facebook, if you don't use it, you're dumb.

I'd quite like to load the LTS version of GMail and Facebook. I'd also like to have some say in how these apps I use every day work. Unfortunately, I have no say. I'm not even the customer.

Re: Trunk-Based Development

#205

Post by Sir_Substance »

foo101 wrote: post #194
Sir_Substance wrote: post #135

Earlier quoted context omitted.

You have a very odd view of rights. It's /within their means/ as a producer to require email to view their content. Just because you can do something doesn't make it your right to do something. Doesn't make it wrong to do it either, but that's god damn miles from a right. In addition, just because you can do something doesn't mean you should, and it's within my means to assert that anyone who asks for my contact info…

> My freedom to express that opinion actually /is/ a right. Sure, but https://xkcd.com/1357/

It's odd that you would link that. From my perspective, I'm the one doing the boycotting and showing of the door. How do you see it?

Re: Trunk-Based Development

#206

Post by Vinnl »

dpark wrote: post #188
shubb wrote: post #182

Earlier quoted context omitted.

Not disagreeing, but a way to avoid this is to pull changes from the main branch into the development branch every day, and write your new subsystem 'beside' the old one until it is ready to go. If you do it like this, it's not much easier for the branched developers than working on the trunk - it's still a moving codebase - but it does mean that if you cancel the rewrite there isn't any pollution to the main branch.

The scenario you called out, where the rewriting work might be abandoned/cancelled, is the only scenario I can think that makes a separate branch actually better. For cases where you're confident that the work will not be cancelled, you have the same amount of work to push the rewrite back into the main branch constantly as you do to constantly keep the child branch in sync. i.e. If you can pull from the main branch…

The disadvantage is that if your rewrite branch is halfway finished, you _can_ merge in the latest main branch, but if you do the reverse (which is exactly as much effort), you're blocking the other developers until your rewrite is done.

Re: Trunk-Based Development

#207

Post by angry_octet »

nhumrich wrote: post #18
hashkb wrote: post #14

Earlier quoted context omitted.

Yes, this is what I think of as CD. Hiding work that isn't ready (or work that may never make it in front of users) behind a flag on prod sounds like extra work for no gain, to me.

The gain is early integration. If you have more than one branch going on at the same time, they can diverge quite significantly, and merging can cause bugs, or sometimes more work. If you only ever have one feature branch at a time, you might as well be doing trunk based with manual deploys to prod.

Can you explain how a repo with dozens of feature flags triggering greatly different code paths, and invisible to the source code management system, is an improvement on feature branching?

How would I use git bisect with a bunch of flags to a composite of build systems?

Re: Trunk-Based Development

#208

Post by dpark »

Vinnl wrote: post #206
dpark wrote: post #188

Earlier quoted context omitted.

The scenario you called out, where the rewriting work might be abandoned/cancelled, is the only scenario I can think that makes a separate branch actually better. For cases where you're confident that the work will not be cancelled, you have the same amount of work to push the rewrite back into the main branch constantly as you do to constantly keep the child branch in sync. i.e. If you can pull from the main branch…

The disadvantage is that if your rewrite branch is halfway finished, you _can_ merge in the latest main branch, but if you do the reverse (which is exactly as much effort), you're blocking the other developers until your rewrite is done.

This is only true if you assume that the rewrite branch will be broken the entire time. You're only blocking the team if your work will be unusable until it's done. If that's the case, then you're also assuming at some point in the future you'll complete the work, get everything working again, and then merge everything back to master. It won't likely play out that way, though.

More likely is that:

* Your child branch will be test-broken and likely build-broken almost the entire time you develop.

* You'll stop taking frequent merges as they become painful because you're clearly not doing the work to patch everything up (and can't, because you've broken everything and likely can't even run tests).

* You'll be "almost done" and then spend three weeks trying to get everything building and testing again.

* You'll tell everyone to freeze checkins because you need to get merged and it's impossible because the branch is so far out of sync and and you're now conflicting on every tiny change.

* You'll finally push your merge back with half the tests disabled.

* The entire team will spend another month cleaning up the mess.

I've never seen a big feature/rewrite branch play out any other way.

Re: Trunk-Based Development

#209

Post by stcredzero »

pjmlp wrote: post #195
chrisseaton wrote: post #181

Earlier quoted context omitted.

How does a team of Smalltalk developers work? How do you merge the binary Smalltalk program image?

With time, Smalltalk also got its own version control tooling. Monticello for example, http://www.wiresong.ca/monticello/

You could consider Monticello as one of the precursors of git.

Re: Trunk-Based Development

#210

Post by Vinnl »

dpark wrote: post #208
Vinnl wrote: post #206

Earlier quoted context omitted.

The disadvantage is that if your rewrite branch is halfway finished, you _can_ merge in the latest main branch, but if you do the reverse (which is exactly as much effort), you're blocking the other developers until your rewrite is done.

This is only true if you assume that the rewrite branch will be broken the entire time. You're only blocking the team if your work will be unusable until it's done. If that's the case, then you're also assuming at some point in the future you'll complete the work, get everything working again, and then merge everything back to master. It won't likely play out that way, though. More likely is that: * Your child branch…

True, in that case you're screwed :)
Post reply on HN