7 ms·

The Origins of Trunk Based Development

35 points by andrelaszlo 11y ago

fishnchips 11y ago
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.
shawnps 11y ago
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 11y ago
  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 11y ago
    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.
- seanwilson 11y ago
  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.
- SideburnsOfDoom 11y ago
  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.
stretchwithme 11y ago
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 11y ago
  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.
  - twic 11y ago
    Wolfpack programming! http://www.cincomsmalltalk.com/main/2010/10/wolf_pack_programming/ http://www.cincomsmalltalk.com/main/2010/10/wolf_pack_progra...
  - stretchwithme 11y ago
    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.
- yitchelle 11y ago
  Is this pair programming 2.0?
  - stretchwithme 11y ago
    Not exactly. More like knowing about potential conflicts when its easiest to avoid them or deal with them more easily.
prodigal_erik 11y ago
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.

35 points by andrelaszlo 11y ago

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.

shawnps 11y ago

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 11y ago
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 11y ago
  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.
seanwilson 11y ago
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.
SideburnsOfDoom 11y ago
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.

stretchwithme 11y ago

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 11y ago
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.
- twic 11y ago
  Wolfpack programming! http://www.cincomsmalltalk.com/main/2010/10/wolf_pack_programming/ http://www.cincomsmalltalk.com/main/2010/10/wolf_pack_progra...
- stretchwithme 11y ago
  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.
yitchelle 11y ago
Is this pair programming 2.0?
- stretchwithme 11y ago
  Not exactly. More like knowing about potential conflicts when its easiest to avoid them or deal with them more easily.

prodigal_erik 11y ago

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.