Trunk Based Development

An excellent resource I found in the Carbon Documentation @khem pointed out:

Branch by Abstraction is a good idea and something I need to do more.

I’ve always pushed for the “scaled trunk based development” workflow and every time I’ve gotten to use it, it has worked very well. I usually call it the fork-and-merge workflow, but basically each developer forks off the main repo, develops smaller feature branches, then sends a pull/merge-request back to the main project’s master/main/trunk branch.

Even if a feature branch from a single developer ends up lagging behind the trunk, rebasing it and fixing the issues is usually pretty easy on anything but the smallest of codebases.

Yeah, same here – I mostly use that flow to the point where I almost never commit directly to the trunk. Doing work on branches in PRs provides the following advantages:

  • notifications to people interested
  • groups commits into larger chunk of work that is easier to review

That sounds pretty similar to trunk based development to me. Are there areas where you feel your workflow is different?

I think the main point of “trunk based development” is that the trunk is the focus of any development, even if the work is done on relatively short lived feature branches. This is different than some teams where extensive work is done on long lived release branches, and it is later merged back upstream (probably more common in kernel development and may be the only option there). This approach emphasizes doing development on the trunk and then cherry-picking back to release branches as needed – less chance of things getting lost or not merged upstream due to merging being too difficult.