I was asked recently about the best practice for using GitFlow with continuous integration. For those who do not know, this is GitFlow:
![Post from 2010: https://nvie.com/posts/a-successful-git-branching-model/](../media/18zDz1s5AtuxyNWmXmfg__2x.png" width="50%"> Post from 2010: https://nvie.com/posts/a-successful-git-branching-model/
There is no CI good practice that includes GitFlow. For continuous integration to meet the definition, these are the good practices:
You're now doing Trunk Based Development. Welcome to your CI/CD journey!
The complexity of the CI automation will depend on how poorly the application is architected and the size of the development team. Monoliths with poor sub-domain boundaries will require much more complicated test design and test execution will take much longer. Evolve The architecture into independent, loosely coupled sub-domains to improve delivery speed, reduce testing overhead, and improve stability, resilience, and scalability.
GitFlow does not increase quality or value delivery. It delays quality signal feedback to the developers, incentivizes manual process, and is incredibly wasteful of time and resources. No modern development uses it.
Some developers have a religion built around GitFlow because it reduces typing (no feature flags needed, no branch by abstraction cleanup, etc.) and they don't track their levels of re-work, lost changes, or conflict resolution. In 2010, GitFlow felt good. We could keep Master "clean". That was almost a decade ago. Testing was still mostly manual. We were still on Java 6. NodeJS was barely a thing. Time to modernize. We don't keep Master clean with add process. We keep it clean with automation.
Update March 2020: I asked the author of GitFlow if he could clarify the use cases to stop the GitFlow whack-a-mole and he very helpfully did so, Please thank him.