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.
The “scaled trunk-based development” from that link is what I generally push for, even with small teams (ie: even when it’s only me or even when it’s just me and one other developer).
1 Like
Trunk based development is a good approach compared to some others methods. However, the key is to have a solid CI which can be trusted by developers and is always kept up to date and relevant as the project takes in new features and scales quickly, its also important to know that when teams grow bigger this can become a challenge, if you have 1000 pull requests per day, how to handle them effectively without conflicts also becomes interesting. So I have been exploring a component based CI where the project refactors into independently testable pieces as it grows and scales. Smaller CI loops is key to success in such scenarios.
oh and an important paradigm, you NEVER release anything from any branch other than your trunk.