Now I haven’t mentioned the STG branch yet. HINT: you can save some merging work if you wait until all new features passes QA, then instead of merging passed features one-by-one to UAT, you can merge the QA to UAT (so all new features) in a single action. NOTE: hot-fixes are applied both to the master and develop branch, but once done, it’s worth to apply them to QA/UAT too – easiest way is to merge DEV to these 2 branches… From this point the classic git-flow applies. UAT approved features can be finished - merged to develop.If QA test fails, you do fixes on the feature branch and once done you merge it again into QA. It stays there until it gets UAT approved. If a feature passes QA tests, it gets merged into UAT.If QA test fails, fixes to the feature branch will will be committed and once finished, it’ll be merged again to QA. The finished feature gets merged into the QA branch.Upon finishing a new feature, we won’t finish that feature (we won’t merge it back to develop).The git-flow introduced before remains the same with a slight change: Testing by the product owner and approval of features for deploymentīy introducing those changes, we make sure that important features gets to the PROD first and it also ensures that the feature implemented works as imagined by the product owner.The standard git-flow does not mention QA and UAT branches. Now what is so cool about using this tool and it’s Git Flow functionality – as you see from the description, when using release and hotfix branches, it automatically takes care of merging the changes not just to the master, but also to the development branch too. I would recommend it as the starting point (together with the picture from the article “a succesful git branching model”). The git client SourceTree also supports Git Flow (and smart branching – see article here ). So let’s see how versioning for these environment can be done with GIT. īut in most cases you manage a DEV/QA/UAT/STG/PROD environment, but the main articles does not mention QA nor UAT. The git-flow is also nicely described in. The “A successful Git branching model By Vincent Driessen” has a nice “all-in-one” picture on how all the types of branches fit together. When it comes to work with GIT there are 3 main articles to read through. Even Microsoft recommends GIT, see: (see heading: Which version control system should I use?) Once you get used to GIT, you learn you can’t do without it. Fast-forward, forced push and so on were new concepts we had to get used to. At start, lot of people felt uncomfortable with it, despite the PROS (like having all version stored locally). I remember when the company I was working switched to GIT.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |