Making continuous integration and trunk-based development habits can be a challenge. I’ve never met anyone (myself included) who was able to switch from the habit of weeks-long feature branches to continuous integration over night.

Changing habits like that takes a while. The hardest part, at least in my experience, is learning to think about “large” features more incrementally and interatively. But there are a few tricks I’ve found that can help learn to think in this new way.

One of the most powerful ones is to determine to merge something every day, even if you still have a long-lived feature branch.

I don’t think I’ve ever seen a large feature branch that couldn’t have something cherry-picked out of it, and merged early. And usually when that’s possible, it’s also desirable. First, here’s how it works:

Imagine you have a large feature you’re working on, but it’s not complete. In the process of building your feature, you discover a pre-existing bug, or you rename an existing variable, or maybe you add some simple utility function to help calculate π to exactly 8,324 digits. Any of these could easily be merged into your mainline codebase, without the rest of your feature, and without risk of breaking anything. In fact, in the case of the bug fix or refactor, they almost certainly should be merged first, to reduce the risk if your feature is later reverted.

So here’s what you do (assuming you’re using git):

1. In your working copy, checkout the latest version of main

2. Create a new branch for your cherry-picked bug/refactor/utility

3. Apply just your single change to the new branch.

   If you’re careful with your commits, you may be able to cherry-pick only the relevant commits from your larger feature branch to the new one. If your commits tend to touch many files, and unrelated features, then you may need to re-apply the change manually, or copy the relevant changes.

4. Push the new, micro branch up to your central server for review and merge.

   Bonus: These small PRs usually get reviewed very quickly, because they’re so small and easy to understand.

5. Once merged, rebase* your large feature branch on top of the new version of `main. Your large feature branch is now a bit smaller than it was before, because it no longer contains your small change. And what’s more: customers, and other developers, can immediately benefit from that change, and you’ll never have to resolve a merge conflict related to it again!

*If rebasing scares you, it would be good to spend some time learning how to do effective rebasing, as in the long run it’s much less error-prone than merging from main into your working branch. But that’s a topic for another day.