Continuous Integration Workflow

1.3 Development Approaches: Git Flow and GitHub Flow

Hi, welcome back to Continuous Integration Workflow. In this lesson we will learn about two different development approaches that are used in modern software development, Git Flow and GitHub Flow. The first one, Git Flow was introduced to the world in early 2010, by Vincent Driessen from the Netherlands. It is a complete release management concept, the targets, version enabled, software products. In this approach, there are two branches that exist indefinitely, the master branch and the develop branch. Master holds the production-ready state of the code, whereas develop holds all delivered development changes or features. These might need to be tested by the QA team to ensure they meet usability criteria and interface guidelines before they can be released. When a release is scheduled, the current state of develop will be branched off into a release branch. This branch will be tested and back fixes will be applied as needed. No new features will be added any more at this point. If there are no bugs and all other checks pass, the release branch will be merged into master, and will be tagged with a version number. It'll also be merged back into develop. After that it can be deleted. If a bug was found in the currently released product, meaning it is in the master branch, A hotfix branch will be created from master. It is only used to fix one or more bugs. After completion, the hotfix branch will be merged into master and develop like a regular release branch and tagged with a release number. It can also be deleted at this point. To develop new features without directly committing to develop, feature branches are created. Developers commit to the feature branches and when they are finished, they merge it into develop. The original idea was that feature branches only exist at the developer's copy of the repository, not on the server. But nowadays it's common to also push it there to prevent data loss. Feature branches are also deleted after they have been merged. This approach makes it easy to manage releases, test them, and produce assets, for instance, release notes or anything similar, and to apply hotfixes without halting the development process as a whole. The second approach I want to show you is GitHub flow. It is an easier model and targeted for code that will be deployed to a single environment like a server. It only consists of a master branch and multiple feature branches. The rules are the same as for Git Flow, master must be production ready at all times. When developing a new feature, GitHub Flow uses PR requests to initiate a discussion about the feature within the team. This means that others can look at the code, try it out, and share their opinions about it. During this discussion the code gets changed multiple times to reflect feedback the developer has received. When there is consensus that the code is ready, you should first match the current monster branch into the feature branch and apply it to a test environment. This verifies that after merging nothing goes wrong with the deployment and causes downtime in production. If there aren't any issues the pull request can be merged and will be deployed to the servers. GitHub Flow encourages discussion and has a double verification principle. Every feature must be tested by another developer. This means it's a relatively simple workflow but also provides safeguards against failures that might affect your production systems. Now that you know about continuous integration, continuous delivery, and different development approaches, we are going to look at our course project in the next lesson. See you there.