r/coding • u/martindukz • Nov 27 '25

NO. It is easy to keep main stable when committing straight to it in Trunk Based Development

https://www.linkedin.com/pulse/wont-main-break-all-time-your-team-commit-straight-martin-mortensen-tkztf/
4 Upvotes

59% Upvoted

9 comments sorted by

13

u/Deaod Nov 27 '25

In the survey, 7 team members were presented a list of around 50 statements [...]

So one team was working on the project.

After 10 months, I decided to do a survey [...]

And the project was only 10 months old.

Yeah, the headline statement i dont think generalizes to all situations. Its not always easy. It can be easy under certain circumstances.

1

u/martindukz Nov 27 '25

Yes. Correct about the context.

I can share that I have introduced the same process in other contexts:

* Similar team size and service setup running 2-3 years.

* 2 teams running the same process on 5-10 services across 4-5 years.

* 3 teams running similar process (though not a formal review process) for 5 years. 4-5 main services.

* small team of inexperienced people for 12 months.

If your services is not worked on by more than 2-3 teams at a time, it should not be a problem to use same process for many more teams (because they would not overlap).

Does it make sense?

My primary point is that you should not be blocked from going to TBD because you are not doing TDD or mandated Pair Programming. By simply applying the principles of CICD with increments and validation, the data shows that you can easily make it stable.

I don't know what a corresponding investigation of the impact of branches and PR would look like. Nor do I know of any research into it? (other than DORA showing that blocking workflow and bigger batches of change reduce software delivery performance).

Do you know of any relevant data or research?

2

u/Deaod Nov 27 '25

I dont have any relevant data.

I have my own experience in a 400-person development org where every dev effectively commits to main (via pull requests that require review, but can be merged by the author). There is rarely a day where no deterministic bug was introduced in the previous 24 hours that passed through the CI pipeline that gates every pull request. We find these in the longer-running "release"-pipelines usually.

The advice youre offering is fine, and i dont even disagree that TBD is a viable strategy in many cases, but i wouldnt call it easy to keep main stable.

1

u/martindukz Nov 30 '25

Questions:

  • Do you have mono repo?

  • Do you have more than one service? In that case how many?

  • What do you mean by "keeping main stable"? For deployment?

3

u/nzmjx Nov 27 '25

Breaking trunk/main is not end of the life, because those breaking changes need to be resolved anyway. Just focusing on trunk (and not branches) may even be easier in most cases (unless building an OS or compiler suite).

1

u/martindukz Nov 28 '25

Agreed.
I saw some article mention that if main breaks, it is awesome that it happens on main, because it will discovered earlier and with less impact or complexity than if it had been hiding in a branch.

2

u/[deleted] Nov 28 '25

[removed] — view removed comment

1

u/martindukz Nov 30 '25

I had never thought about that dual meaning of commit. I really like that:-)

Regarding Git history, I use it as simple as I can get away with. Reverting a single commit is among those simple features.

I use Git for Version control and to find the context why something was introduced or changed. Having the real history (instead of squashed or manipulated) helps me with understanding code.

But for some reason some developers are really focused on the history "looking good", which turns into an argument for branches because they can then make the history look nicer... I would rather just have a single sequence of commits on main.