This contains work that will be delivered into the next release. It also contains all the tags for each release that was made.ĭevelop contains work that has recently been integrated from features. Master contains the last released version of your application, code that’s in a production ready state. Git Flow basically has the following different types of branches: Git Flow Diagram – taken from Vincent Driessen’s blog.
I found a diagram which I think describes Git Flow really well. How I felt using git before discovering git flow.Īfter getting burnt a couple of times, a colleague of mine introduced me to Git Flow. Problems with this approach include: Branches stemming from different sources, branches created from other branches and not knowing what to do if there is a bug on production but there are new commits on the develop branch. As soon as there are more developers on the team, things quickly become difficult to manage. This method of using git works ok for small sized teams of 2 – 3 developers. Releases were made by merging develop straight into master branch and tagging the commit with the release number. This can be very problematic and losing code is easy to do. If a person is in mid-feature or testing something out, often they wouldn’t commit their work until they were done, keeping their code only on their local machines. I have observed a couple of teams and their approaches to using git, and generally teams have two branches: master and develop. Often teams don’t take full advantage of Git’s capabilities. Developing in a small team is pretty manageable as you generally see the code that is changing and can easily monitor these changes.
0 kommentar(er)
