The Origins of Trunk Based Development | Hacker News Reader

The Origins of Trunk Based Development

paulhammant.com

35 pointsandrelaszlo14 comments

I think it would be useful if IDEs allowed a team to share when multiple people are editing the same file at the same time. And even get notified when such a change gets committed so you merge it right away. And I don't mean just watching the repo.

Sometimes two people are working separately on the same bug when they could be collaborating. Its also easier to merge changes one by one, instead of dealing with 10 at once. And if a change is completely incompatible, its best to deal with that when the code is committed, not a week later.

It would also be cool if there were chat integrated with that, with a history that gets linked when you commit so you can understand the context later.

Google docs for code. That's doable. Heck you could do it today using google docs, simply set that up as your editor. No code completion, syntax highlighting and other goodies but it might just work for some collaboration.

Wolfpack programming!

http://www.cincomsmalltalk.com/main/2010/10/wolf_pack_progra...

I don't mean working on the same piece of code at the same time in the same editor.

I mean working independently but being informed about the efforts of others working on the same piece of code. I think it might be potentially distracting to have other people deleting your code as you write it.

Is this pair programming 2.0?

Not exactly. More like knowing about potential conflicts when its easiest to avoid them or deal with them more easily.

Visual Studio 2015 has started on this road. I dont know if you get notified but you can see when the last change was, and in theory if changes are incoming.

No idea how well it works because it was really slow because it seems to come bundled with other features that require indexing of your entire project so I disabled it

I've worked with a few different branching styles, including:

1. Feature branches that get merged into master via PR in GitHub

2. Sprint branch, bug fix branch, and master

3. Developers push directly to master (or if they really need a code review, push to a branch)

So far I prefer 3 the most, then 1, and I hope I never have to do 2 again. 3 is fastest, and we write a lot of Go so many of the comments I would have made on a Python PR for example aren't necessary.

I've worked with all of these as well, and also like 3 the best. What level of manual testing, unit testing, etc do you use? And do commits to master automatically get deployed?

Currently at work, my team currently pushes directly to master, or sometimes to a branch that is merged depending on the size of the work. Code is autodeployed to a staging environment, and then manually promoted to production a few times a week after smoke testing.

We have lots of unit tests and a fair amount of integration tests. There is a staging environment as well, and I personally do a bit of manual testing whenever I push just to be sure nothing is catastrophically broken.

Commits to master don't get automatically deployed, and we deploy manually to staging then to production. I like the idea of automatically deploying to staging. It takes one more step out of the process.

When I worked at #2 there were 0 tests, which I believe is why management was often so afraid to deploy. Of course things are going to break if there are no tests. It took me a year to convince them to add unit tests, but we got there eventually.

I find it can depend on the project. I've been forced to do 1 for a project being developed from scratch and found the constant branching and merging really annoying and slowed everything down. Once the a project is large enough however, feature branches make a lot more sense as new additions to the project need more careful consideration.

Yep, I've done these and #1 (all code is PR'd and reviewed) can be a right pain for technical and political reasons, and results in much slower progress and poorer overall code.

PRs are a wonderful mechanism to provide smooth but gated access to the code for people outside the owning team who otherwise would not have it at all; but inside the team, I think: just because you can do it does not mean that you should.

This article is completely silent on QA. You have to be able to commit code that isn't finished so it can be reviewed and tested (as well as for disaster recovery), yet you don't want other people building on it because it might have severe problems.

As far as I can remember a lot of Google folk used Git on top of the 'mega-trunk'. Not sure though if this was or was not the majority.

Reply on news.ycombinator.com