
The Origins of Trunk Based Development - andrelaszlo
http://paulhammant.com/2015/04/23/the-origins-of-trunk-based-development/
======
stretchwithme
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.

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

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

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

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

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

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

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

