Gitflow VS Task-Driven Development

[diegohb]

Have you guys written anything comparing gitflow against the task-driven development process explained at the link below: https://www.plasticscm.com/branch-per-task-guide/intro/why-is-branch-per-task-better.html

I know gitflow can be accomplished with Plastic as well but I'm arguing that maintaining a long-lived integration branch "develop" and a separate branch for "production"/master that triggers deployments is bad. I'd like the exact same check-in i created to be the codebase that feeds into continuous integration and deployment pipelines...  i'll edit and add links for reference and try to clarify.. but wondering if there's anything written already on this topic.

[psantosl]

Hi Diego,

Believe it or not, but we have been discussing about writing a new guide, including new patterns like trunk based development :-). So it seems you just read our minds.

We would like to write a short book about best practices, but probably we will start with a short blog post describing what we consider "the perfect cycle".

 

Since you are interested on it too, we'll try to publish something short asap to open the discussion.

 

In short, some remarks:

* I prefer to have short lived task branches that only individuals use.

* Get them automatically merged by CI once they are peer reviewed and they pass all tests.

* This way main is always ready to release.

* And you use the lower possible ceremony.

This all connects to trunk based development (do not confuse with *just checkin to main*, is not that thing), and we really like the pattern.

 

 

pablo

 

[diegohb]

Agreed.. those are also important to me..  I've also always asked my team to do frequent commits and ensure they aren't unnecessarily checkin in formatting changes so to not create "noise" when someone wants to walk through their thought process in code reviews..  I don't quite understand the reference to "trunk based development" but I'll wait for the write-up from you guys. :-)

Gitflow calls for having a separate production branch (master) which should be comprised of commits that are pulled from an infinite integration branch called "development"  ..  i think that this violates some of the principles of continuous integration and delivery that call for the commit to lead to a single build that is then passed into the entire deployment pipeline (http://www.informit.com/articles/article.aspx?p=1621865&seqNum=2).  It's a subtle distinction but I think it's very important that technically, a different commit/checkin that generates a different GUID/CS#, means that technically, it cannot be assured to be the exact same code that developer intended to push out and promote throught he CD process..

 

-- i didnt realize i had already mentioned this on my first post above.. oops. I very much like the process generally described as "task-driven development" at https://www.plasticscm.com/branch-per-task-guide/intro/why-is-branch-per-task-better.html.