I have a question about …

I have a question about trunk-based development. I consult with enterprises on their development practices - particularly on the project management side. Probably the single biggest problem the teams I speak to have is that business people in general are really bad at breaking down their asks. There are other problems, but this one is generally the hardest to fix. We’ve had success using GitFlow to introduce the concept of “Features”. Business people get this. Trunk-development sounds super-lightweight. Do you lose something if you still use feature branches? If you have used feature-branching before, how would you compare it to trunk-development.

Responses:

You can still have feature branches. The whole idea of trunk-based development is to integrate with the main line as often as possible and possibly with a “fast-forward merge” s.t. the main line history is flat.

what’s important is to have short-lived branches

(which is a good idea in general)

as a “workaround” I’ve also seen ppl use feature flags. S.t. they can merge fast but still not expose the potentially unfinished code to others.

this site is really good: https://trunkbaseddevelopment.com/

All of the above. My team also uses GitFlow (or a variation thereof), using branches for development and pull requests for code review. We either rebase or squash the commits into the default branch, so we can keep a flat history

Do your team use stacked PRs?

Sure when it makes sense, but we try to avoid it. GitHub doesn’t really support a PR depending on another PR, so we usually keep the second PR as a draft or at least label it in some way to make it clear.

Interesting, thanks!

Wow, thank you so much! Great answers. If you don’t mind one last question - how are projects managed where you are? Agile? What works well/not well?

Also https://trunkbaseddevelopment.com/ is super helpful. Thank you for reccomending it.

Agile, but I don’t think it makes a big difference tbh. Agile projects “should” have smaller buckets and thus make it easier to merge small buckets in PRs => have more short-lived branches.

But in the end it’s always the devs that should manage the git branches…it’s not something that should be related to the metodology that is being used for organizing the project :slightly_smiling_face:

(but I totally get why you ask :slightly_smiling_face: )

Thanks Juri. I am trying to find a way to help dev teams and business people communicate better. A “feature” is closest I’ve come to a reasonable intermediary between Epic and Release. I like the way NGRX defines features… Actions are something tangible that business people can understand. A feature being a list of actions - this is workable on many levels.

I appreciate any and all feedback/advice! Thank you!

Great points indeed, short-lived branches with a well delimited scope / set of changes for easier review. Just rebase if something else gets merged first and squash commits before merging (most of the time) to keep the history “readable”. Merge into the mainline and forget about Git flow

An excellent summary of the workflow our project is based on is Gitlab flow: https://docs.gitlab.com/ee/topics/gitlab_flow.html