Hacker News Reader

Comment by damnyou | Hacker News Reader

This is called trunk-based development, and it is the only development model that scales to thousands of engineers in one repository.

View on HN

It's also called "continuous integration."

As in everyone continuously integrates their changes, and you strongly discourage divergence.

https://en.wikipedia.org/wiki/Continuous_integration

In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

https://martinfowler.com/articles/continuousIntegration.html...

One of the features of version control systems is that they allow you to create multiple branches, to handle different streams of development. This is a useful, nay essential, feature - but it's frequently overused and gets people into trouble. Keep your use of branches to a minimum. In particular have a mainline: a single branch of the project currently under development. Pretty much everyone should work off this mainline most of the time. (Reasonable branches are bug fixes of prior production releases and temporary experiments.)

While I do like this approach, it can cause some pains though.

It's often a race to get your (approved) merge- or pull- request in. If you miss out, then you rebase, and try again. Perhaps if your pipeline is super fast, it isn't an issue.

Another issue is that there still needs to be coordination outside of version control/CI pipeline to ensure that things are put in the 'right order', for the times when that is important.

Developers rarely push directly to master in large organizations. Instead, a CI pipeline verifies your code passes tests and then pushes to master.

There are trade-offs here around "semantic merge conflicts", but they happen rarely in practice. To avoid making this disruptive to developers, you can have another branch that marks the latest commit to pass tests. This branch should always be an ancestor of master and should only be updated by your CI pipeline.

> Developers rarely push directly to master in large organizations. Instead, a CI pipeline verifies your code passes tests and then pushes to master.

Yup, that's what I was referring to with my 'merge- and pull- request' line.

Interesting idea about having another branch.

And why not. Rebasing should be much more straightforward/common. I remember at one point I had a 'magic' command that just did a rebase the way I expected and allowed me to merge changes in easily; it quickly made its way through the group I was working with.

Reply on news.ycombinator.com