Committing straight to the trunk
Some teams will choose to commit straight to the trunk. Most likely it is because they are a small team with each
team member knowing what the others are up to. Their build is probably fast and relatively exhaustive, and they
may well seldom experience a build breakage. If the build does break (post commit) then they most likely ‘revert’ the
commit straight away, possibly locking the trunk for a short period of time while that is sorted out. The team may be
really small (say three or four), in which case the team might allow someone to fix the build quickly and commit the fix in order to get the build green again.
In the 2000’s Trunk-Based Development teams might have numbered up to 100 committers. They may have been extremely
rapid with their
reverts (lock trunk, revert, kick off the CI daemon again, unlock trunk if green again). If not would
have performed check-in activities that the 1997 C3 team would have recognized, because they wanted that human
assurance that gated check-ins are all that is needed to keep the build green. Namely, developers holding an
“I/we are checking in now, nobody else should be”. They run the full build after bringing their checkout up to date
and commit/push if green. Indeed that ceremony is a key part of the Continuous Integration advances
and is now part of Agile generally, and Extreme Programming in particular. These days teams doing this practice are likely
to be much smaller (say less than 16) because of the advent of a modern alternative.
Alternatives to committing straight to the trunk
That modern alternative that allows teams be bigger without having a bottleneck around check-ins: Short-Lived Feature Branches.