one of the more popular certainly more widely recommended approaches to managing change into production is git flow i confess that i've never been a fan i'm a continuous integration guy and git flow prevents real continuous integration for a long time ironed people like me who value fast efficient ci over feature branching have felt that we were kind of talking at the margins i think that many if not most people disagreed with us on this however one of my friends has recently had some success in moving the conversation on a bit so i thought that this may be a good opportunity to explore git flow and its use in a little bit more detail so what is git flow and why is it incompatible with continuous integration and continuous delivery [Music] hi i'm dave farley of continuous delivery welcome to my channel and if you haven't been here before please do hit subscribe and if you enjoy the content today hit like as well i'd like to begin by thanking our sponsors harness equal experts octopus and spec flow they're helping us to grow our channel and so please do support them by checking out their links in the description below if you'd like to know more about my preferred approach to continuous integration and branching check out my training course anatomy of a deployment pipeline where i'll cover this in a lot more detail git flow was invented in 2010 by vincent driessen this was the same year that my book continuous delivery was published so git flow is certainly not designed with development approaches like cd in mind really this is the git flow model it's based around two branches usually called develop and master this approach is based on the use of git hence the name and even though one of these branches is called master the name choices are somewhat arbitrary really doesn't mean the same thing as mastering does in git git is a distributed version control system meaning that every clone of the repo is the same so the selection of a one true branch for master is purely by convention not imposed by git itself supporting these branches are a bunch of others feature branches release branches and hotfix branches so five different kinds of branch in all but in practice there may be many more branches than that in play because there'll be multiple versions of feature hotfix and release branches this is a complex branching strategy and as i said in the intro works against continuous integration having said all of that i have employed branching strategies like these on projects in the past but that was before i learned how to do continuous integration properly so what do i mean by it works against ci here's one of my favorite descriptions of continuous integration from the inventors what if the engineers didn't hold on to modules for more than a moment what if they made their correct change and presto everyone's computer instantly had that version of the module continuous integration is about establishing and maintaining a shared accurate view of the state of the system that we're working on we aren't guessing whether our changes will work together we're checking frequently multiple times per day continuously here's another quote from the c2 wiki description that i like the fundamental assumption of continuous integration that there's only one interesting version the current one let's look at where we can achieve that clear correct picture of the current version in git flow is it here on the develop branch well it's close but it's not definitive what if we evaluate our changes as we commit them to the develop branch is this really the truth no this isn't the collection of changes that will definitively end up in production we may have hotfixes that haven't been merged back into develop yet so develop and master r for a short time out of step maybe we made some changes to develop that we decided at the last minute not to release for some reason so all of our evaluations up to that point were based on incorrect assumptions i can imagine fans of git flow at this point now smiling and saying dave doesn't understand we work to keep the developer master in step well let's pose the question the other way around if develop and master are kept really close together in terms of changes what's the point of having both and so risking them being even for a moment out of step why don't we instead use our version control systems to do its job and control the versions that we're interested in so i can imagine using the developed branch as the truth but that would eliminate the need for the master branch and the hot fix branch altogether merging all of the changes into develop whether new development hotfix or bug fix and releasing changes into production direct from there but this is now just continuous integration or maybe continuous delivery not git flow we can think of the master hotfix and release branches as release supporting aspects of this approach they're all focused on managing change into production this is obviously important the truth of our system is what ends up in production so i think that should be the focus of our evaluation so we could decide instead of treating develop as the truth to evaluate our changes every time we merge a change to master this would be accurate in terms of the changes since that's where we release from master into production this is the interesting current version the only that only works in a continuous integration sense though if we're doing that multiple times per day by definition continuous integration says that everyone's merging their changes together at least daily we are also still left with the special cases of hot fixes or bug fixes what's the current version now the assumption that i think is built into git flow is that we do this merge when we think our work on a feature or bug fixed is complete if we're waiting until we think we're finished before getting feedback on our work though that's crap feedback it doesn't really support development and it's certainly nothing close to continuous integration so we need to up the rate of merging to master the most sensible way to do that is to eliminate the develop and hotfix branches and now yet again we're back to continuous integration as well as all of these release supporting branches there are feature branches i've spoken about my thoughts on feature branching before in previous videos it's really the same line of reasoning that we've just explored for release though as a developer i want the clearest possible signal that my changes are safe to release and i would much prefer to find out that my changes aren't safe to release close to the point from at which i begin to diverge from safety rather than after weeks of now wasted work even if the work isn't completely wasted i'm not where i thought i was now i've more work to do than i planned because i need to get back to safety so i'd like feedback on the safety of my changes frequently so that if i do make a mistake i'll find out really quickly so that my mistake would have been a small one what does safety mean in this context well it really means that our changes are releasable the change is of production quality it does the job we expect it to it works along with everybody else's changes this is the problem that continuous integration was invented to solve so in a perfect world what we'd really like is constant you may think continuous feedback on our changes every moment you know that your changes work along with mine and we both know that our changes together are good enough to release the problem is that the world isn't perfect so there are some compromises in reality i don't really care whether your code compiles with mine while you're in the middle of typing character by character that would be too continuous so we break it up even in continuous integration there are times when i'm working on my local copy and you on yours but if we want this semi-continuous picture of the combined safety of our changes then we can't afford to wait for too long in continuous integration most experts agree that daily integration although too infrequent to be ideal is just about good enough to qualify as continuous integration so if your feature takes longer than a day to create you can't wait till it's finished and so do feature branching before you merge your changes if your feature takes less than a day to create what's the point of creating a feature branch my preferred way to organize all of this is that i will work in my local repo on my copy of master i'll commit changes locally frequently usually just after the test that i'm working on has passed after every successful local commit i will push my changes to origin master where that triggers the first stage in my deployment pipeline which is really just continuous integration some version of this is sometimes referred to as trunk based development though i confess i don't really think that there's any real difference between this version of trunk based development and continuous integration you aren't really continuously integrating if you aren't learning to trunk at least once per day now git flow adds all of these other branches branches by definition are defined to isolate or hide change continuous integration by definition is designed to expose changes these are kind of mutually exclusive ideas at the start of this episode i mentioned some recent moves on this topic these are down to a friend of mine brian finster who reached out to the inventor of git flow vincent and asked him to revise his explanation in the context of continuous delivery i think it says a lot for vincent that he did so vincent's article that introduced git flow now has an update here's a snippet if your team is doing continuous delivery of software i would suggest to adopt a much simpler workflow like github flow instead of trying to shoehorn git flow into your team now clearly i've taken a step further than vincent did i contend that if you aim to practice continuous integration not the its bigger brother continuous delivery you need to find an alternative to git flow there are a few other things that vincent says that i disagree with too continuous delivery certainly for more than simple web apps that he refers to ask tesla erickson or siemens if you don't know what i mean but i do want to thank him for making this change i think it was an honest uh and a respectable move thank you vincent brian wasn't done though the number one hit when you google for git flow is on the atlassian side it now reads as follows git flow is a legacy git workflow this was originally disruptive and novel strategy for managing git branches git flow has fallen in popularity in favor of trunk based workflows which are now considered best practices for modern continuous software development and devops practices git flow can also be challenging to use with continuous integration and continuous delivery this post details git flow for historical purposes in vincent driessen's revision he mentioned github flow as an alternative this is certainly a simpler approach than git flow but it's really just describing a feature branch model in github flow you do all of the work on a branch until you think it's finished so the problem is speed and accuracy feedback once once again the description that vincent links to doesn't mention continuous integration or testing of any form at all i think that's a big mistake so i wouldn't recommend github flow either i think that this omission of any mention of testing in the descriptions of both git flow and github flow is a significant one to me both of these strategies read as if you'll forgive me sticking plaster fixes for teams that don't do a great job of automated testing the slowdown is that inaccurate feedback enforced by both of these approaches as a problem for continuous integration it means that we wait too long to find that we've made a mistake but it's inherent to the approaches their aim is to give you time to look at and check your work thoroughly i think that speeding up the feedback cycle is a much better solution to this it brings the problem into clearer focus it allows us to evaluate definitive collections of changes together rather than a best guess approximation of what is likely to be deployed into production the real issue here is how confident are we that our changes are safe git flow and github flow try to make the change process safer by slowing things down allowing more time presumably for developers to think and check their changes manually or with automated tests on one of one of the several branches but as a result of slowing things down and reducing the frequency of integration the testing on these branches even if it is very thorough evaluates collections of changes that aren't the same as what end up in production so it's not definitive i think that continuous integration makes people nervous because we're exposing changes before developers are finished with their their features that they're building this is a big change in how we approach our work it forces us to think and work more incrementally but this approach more closely represents the reality of software development in reality this incremental approach at the heart of continuous integration works not just for simple websites but for some of the most complex software systems in the world taking a genuine engineering approach to software development sometimes means that we have to face difficult realities in this case i suppose it comes down to what is the biggest risk working so that our software is always working as we do in continuous integration or even working so our software is always releasable as we do in continuous delivery or slowing things down and working in isolation and keeping our fingers crossed that at the end our changes will work alongside everybody else's the data for that is in continuous integration works better even though it means adapting the way in which we approach our work to make it work thank you for watching [Music] you