3 ms·

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

dorian-graph 9y ago
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.
- damnyou 9y ago
  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.
  - dorian-graph 9y ago
    > 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.
- nebabyte 9y ago
  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.
mbrock 9y ago
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 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#PracticesOfContinuousIntegration 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.)

dorian-graph 9y ago

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.

damnyou 9y ago
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.
- dorian-graph 9y ago
  > 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.
nebabyte 9y ago
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.

mbrock 9y ago

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 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#PracticesOfContinuousIntegration 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.)