3 ms·
It seems to me that most of the authors objections stem from 100% strict adherence to git flow, which IMO is the wrong approach. I loved the concept of git flo
by bavell 7y ago
It seems to me that most of the authors objections stem from 100% strict adherence to git flow, which IMO is the wrong approach.
I loved the concept of git flow when I first read that legendary blog post. I learned a lot and adapted it into my own development workflow. I've bounced back and forth over the years in how strictly I adhered to the One True Way (tm) based on how well it worked for me in actual projects.
IME I think the best approach to git flow is to learn and understand it and then adapt it to your project's workflow, as opposed to strictly adhering to every tenet of git flow. I have multiple projects using different "amounts" of git flow - e.g. a large project with dev, qa, hotfix and release branches vs a small personal project with only master and dev.
- dvdgsng 7y ago> 100% strict adherence to git flow, which IMO is the wrong approach. I agree, as with most things, there certainly is room for flexibility here. One problem I've seen repeatedly occur when migrating to git flow is a misconceptions about 'bugfix/' branches, which are intended to be used when stabilizing a 'release/' branch. However devs use that prefix for every bug they find which is not related to a story/feature. And to be honest, they are right to do so. The naming is just bad here, since the term 'bugfix' is so generically used, it's not very intuitive to use it only for release branches. So I've come to the point where I would agree to use 'bugfix/' for regular bugfixing if the team/company is comfortable with it, even though it is opposed to original gitflow.