Detail of the advantages over trunk-based development with short-live feature branches would be great :)

[paul-hammant]

Ref: http://trunkbaseddevelopment.com/short-lived-feature-branches/

And GitHubFlow - https://guides.github.com/introduction/flow/ :)

[rocketraman]

@paul-hammant Thanks for the question!

I like trunk-based development for continuous delivery pipelines for hosted services (like GitHub, and pretty much anything Google) as well as most simple projects (like this one!). In this model, you make small changes and deploy them quickly -- your first link indicates branches should only live for about 2 days at most -- and that becomes the new baseline on which everyone works.

So the sweet spot for gitworkflow as opposed to trunk-based dev is probably mostly applications that need periodic releases:

• non-hosted applications that are packaged up and deployed to users
• hosted applications that support critical business services in which changes / additions / removals have to be communicated to users, release notes created, training given, perhaps downtime plans made, etc.
• complex monoliths in which it is possible a tester will defer a feature to a later release, or a feature won't be completed in time, and it was not possible or desirable due to increased effort to break it up into smaller chunks
• applications with spaghetti code that make it difficult to apply abstractions-based branching and similar techniques without significant extra effort

For these cases, I don't think a trunk-based development approach provides the same level of flexibility. For example, with a gitworkflow approach a feature (or "topic") being worked on does not have to graduate if it is not yet release-level quality -- it can remain alpha or beta-quality code.

Thoughts?

[paul-hammant]

Thanks for the response, Raman.

I see TBD + BBA✝ + feature flags/toggles play to the same four bullets you're highlighting. Indeed, my biggest personal client achievement in 2005/6 was for Bank of America's GFX team in Chicago, doing a legacy rejevenation. I'd link to my more commercial materials on a diff domain but GitHub has rules about that.

The 2-day SLFB's is what we recommend for TBD (and CI), yes. That'd even be true for a longer-to-achieve things, which is why I utilized (then documented) "✝Branch by abstraction" in the BofA mission. Some things are easier in Java though. At least with Intellij as the IDE (yes even back in 2005). Much easier than they are in the C/C++ world with any IDE, I'll claim.

[rocketraman]

Hey @paul-hammant, I certainly agree with you regarding Java and IntelliJ IDEA -- amazing IDE and wonderful for refactoring. I've used VS pretty extensively and it doesn't hold a candle to IDEA. Feel free to send me a PM with the links, if you don't feel comfortable posting them here (I wasn't aware of any GitHub rules to that effect -- those types of guidelines would normally be set by repository owners).

It was fun to read you were the co-creator of PicoContainer. I used to use Spring extensively (which was all setter injection in those days), and I credit PicoContainer with introducing and popularizing constructor injection, which is pretty much the norm for all DI frameworks now (including Spring).

If a project is willing and able to implement BBA, and doesn't need the capabilities afforded by integration branches, then TBD is the simplest possible reduction of gitworkflow (topic-based development, with 0 integration branches). I submit, however, that integration branches are often useful -- gitworkflow by default has 2 of them (next and pu, not counting maint) but that can easily be simplified down to 1, or even determined on a per-topic basis. Nothing at all prevents someone that uses gitworkflow from merging a topic directly into master.

[rocketraman]

Re-opening this because its probably worth talking a little about this in the main documentation.