My understanding is that trunk based development should rely on direct commits to master or short-lived feature branches that are merged with master. Incomplete work can be placed inside functions that are then toggled off with feature flags.

For short-lived feature code review: developers can work together in person to review work before/shortly after it is committed to the master branch, or they can create pull requests from their short-lived feature branch to master and review before merge.

I'm working on a project where code review would be beneficial and currently a lot of the team's (3-4 juniors and 1 Sr.) features are long-lived. It seems like the code review approach would be to use feature flags to hide incomplete work, and then have developers break a long-lived feature out into discrete chunks of work that live on short-lived feature branches. These can be reviewed via pull request as the feature progresses to completion.

The reason I'm considering recommending this flavor of trunk-based development over GitFlow is because the Git knowledge there is thin so fear of merge conflicts looms large for the team. They also currently practice trunk-based development except that they don't have automated testing, use branches, perform code review, and don't use feature flags so deployment get delayed because of unfinished work sitting on master.

  • 1
    The branching model has no effect on the number of merge conflicts you generate. At worst, it delays the point in time when you are forced to deal with it. Commented Feb 20, 2020 at 1:40

3 Answers 3


There really isnt a qualitive difference between git flow and trunk based patterns if you use feature branches.

The problem that trunk based is supposed to solve is those long lived feature branches that never get merged and the merge conflicts they generate when you finally do merge them.

Instead it says "just merge what you've got, as long as it compiles it doesnt matter"

I would recommend however the only real solution is smaller features.

  • Merge everything you have now and make it build.

  • Comment out the bits that dont work (stop gap, while you get back on track)

  • Start again but this time with nothing that takes more than one day to add.

So instead of "Add a Shopping Cart" have "Add a button", "Add an Image"... etc

  • So the 'comment out the bits that don't work' part is the part I don't like, if it's a simple feature this works but when the feature spans multiple files in multiple places it's hard to keep track of. Have you run into this problem?
    – Stu
    Commented Apr 24, 2019 at 20:04
  • 1
    i wouldnt recommend it normally, but you have to dig yourself out of the hole before you can start working properly. Its better to merge and comment quickly and simply than try to cherry pick or work out a clever merge strategy
    – Ewan
    Commented Apr 24, 2019 at 21:21
  • Oh ok, I misunderstood that the 'comment out' part was a stop-gap, because that's the current long-lived solution
    – Stu
    Commented Apr 24, 2019 at 21:33

The purpose of pull merge request code reviews for my team is to reduce the blast radius of team members so they don't break everyone involved. Ideally they should be small, but there's generally enough trust on the team that as long as it works and you own up to any issues we usually do away with the reviews.

However, when a developer isn't sure about something we usually initiate the code review process (which happens with the Jrs). Sometimes when they're not used to it, the branch will have many changes which we need to "correct" by getting them to understand that a code review is much like doing a review for essays.

  1. If it is long then the message gets lost.

  2. If the style is bad then people get annoyed having to read it.

  3. If a machine can find bugs why am I as the reviewer have to read it?

For 1, we just need to make sure it is smaller and they send things for review asap. And push and get stuff merged to master when it is small and confident enough that the developer can push it up.

This needs #2 to be in place. For that we just use automatic tools like tslint or Eclipse Save Actions (with project level formatting rules). Of course that just deals with stylistic and relatively trivial errors. The last one costs money, but we are able to get away with the free tier since our team is small.

Item #3 uses an analysis tool that performs more robust checks that being SonarQube. That also allows us to see the progress through time on the code quality and improves the confidence of the developer because they'd get a lot of small junior mistakes out of the way and also track their code coverage for their tests.

Ideally if you can afford it, get the developers version so you can get branch analysis, like I said I am cheaping out on it because we inheritted 300k lines of legacy code and the cost factor for it is ridiculous. That and not many people in the team are complaining that we need the developer's edition at the moment (it's just me as the tech lead that's complaining but also being cheap about it at the same time).


Stable code, with some beta features on it.

Tested thoroughly by the developer itself before committing.

The smallest commits.

If any bug is discovered, that is fixed before continuing coding anything else.

Juniors are reviewed, seniors aren't. Double reviewing of seniors is a huge waste.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.