1. Throughout this series you've seen the number of branches that we use in order to manage our workflow growing. So to begin with, we started with a single branch called master and this is the branch that gets created when our repository is originally initialized, and we did all of our development on that branch. We even created a remote repository and cloned that repository in a production environment using just that branch, and we were all able to sync up code from our development site up to our production site and back again. Now, if you're a one-person team, this single branch model could be sufficient for you, but near the beginning of this series we explored using a feature branch in order to pull out our code into a separate branch and begin working on a feature making a series of commits to that feature before rolling it back into the master branch, the purpose of that being that we can create multiple feature branches and be able to polish our code on those features before pulling it into the main branch which will be pushed eventually to our production site.

2. Having our changes on that feature branch allows us to roll back simply by deleting the branch instead of having to roll back individual commits. So where this model starts to break down where we're using just a master and maybe some feature branches is when it comes to releasing to a production site that needs to be very stable; or maybe stability isn't a huge problem for you, but you have a larger team working together and so you need to make sure not to be stepping on each other's toes and breaking each other's development environments. In those situations, we need something a little bit more.

3. So one thing we did in the last video is we created a development branch and we made that the central branch where our development takes places, and then only when we are ready to release our code to our production site will we then push it straight to master. What this does is free us up a little bit to use that main development branch for actual development without having to worry too much about updating master and accidentally pulling in non-tested code. But there is still a couple of problems with that model, which is since we're using our development branch in order to push directly to production, that development branch could have some unmeasured features or some changes that we don't intend to push.

4. Also, it doesn't really give us a chance to test out our release code before we put it into production. In most website projects where stability is very important, where there is a large number of users or the types of users are very important to keep happy, then there will be a staging environment which is basically a duplicate of the production server where a new release is tested rigorously before that release then gets pushed to the production site. So a branching model that matches well with this model is to develop in the develop branch; and then at some point when you're ready for a release, you don't push directly to master, but instead you push to another branch called a release branch and that's the branch that you use on the staging server in order to test the release.

5. Now, as you find bugs and missing features on this release branch, you make fixes to that branch directly; and at the same time, there is still development going on in the development branch where people are adding new features and bug fixes that are going to be added to the next release. When the release is done being tested, it's then pushed to production and any changes that were made to this release are then merged back into the development branch in order to carry them forward to the next release. At that point, the release branch has had its life.

6. So then, what happens if we've pushed the release after we have tested it to the master branch, it's on production now and we find a bug? Well, this release is actually complete. We pushed it to master and we tagged it with a particular release version and we push those changes back to the development environment, and then we actually deleted this release branch because we are no longer going to make any modifications to it. Any bugs that we find that are now on the master branch are going to have to be fixed in a new release.

7. Now, some bugs are so important that they can't wait for the development branch to be ready for a new release. So a solution to this is to create another type of branch called the hotfix branch and what this does is it branches directly from master so it's got the same code base and then you make modifications to fix the bug, and then you merge it back with master, creating a new minor release of your software, of your application or website, and then you bring it back into development so that it's incorporated in the next release. Now, if you're new to version control and you are new to this whole concept of branching and merging, this is going to feel a little bit complex and a little bit overwhelming, and so it's totally okay for you to stick with a simple branching model using just the master branch, and experimenting a little bit with feature branches will get you a long way.

8. The rest of this setup though is a robust workflow that will work at any scale of project. So once you wrap your mind around it and maybe even employ it in your own projects, you're ready to work with a larger team; you're ready to work on projects that need great stability; and so it's a really good skill to have. Now, this whole branching model where there is master, develop, feature branches, release branches and hotfix branches is called Gitflow.

9. Now, a lot of the concepts in this model aren't really new, but they were brought together in this unique way to work with Git by a fellow named Vincent Driessen, and you can learn more about the model by going to nvie dot com slash posts a-successful-git-branching-model, and you see he's got some great diagrams here and he explains the purpose of each type of branch and what rules are associated with those branches. What's particularly excellent about this model is that even though it seems complex at first, this is really it. It's limited in its complexity.

10. Once you understand the purpose of each branch and integrate it in with your workflow, you really don't have to go any further than that when it comes to a branching-merging model. So in our next steps what we are going to do is talk through the creation of a release branch, a hotfix branch, and a feature branch and how to integrate those branches with a local development, a production and a team member's environment.