Git flow overview

- [Instructor] The first workflow that we'll cover is Git Flow. For years, it was the preferred workflow for most teams. But as more projects have shifted towards modern continuous delivery practices, it's become less applicable because it wasn't designed to support such rapid release cadences. That might make you wonder why it's important to learn Git Flow now. Well, since Git Flow was so popular, it's still used in many projects today. So the chances are high that you might encounter it in the workplace. Also, for teams that ship their software on a monthly or quarterly cadence, it's still a viable option. So let's take a look at Git Flow from a high level. It starts with two primary branches named main and develop. These are long-lived branches within the team's shared repository. The main branch stores the project's production ready code. So it holds the code that can be or will be released to production. The developed branch contains all of the development changes that are being worked on for the next release. It's the branch where developers integrate their changes and pull the changes of their teammates. When the code in the developed branch reaches a stable point, it will then go through a series of merges that eventually place the code into the main branch. We'll go into more detail about this later. But first, let's talk about the three types of short-lived branches that support this workflow. The first is a feature branch, which we've discussed. Developers use it to track the work they're performing on a single feature or bug. A feature branch is created by branching from the developed branch. And it's important that the feature branch is only used to work on a single feature. Once the work on the feature is completed, the feature branch is merged back into the developed branch on the shared repository using either a poll request or a local merge, and then a push. When the team has integrated all the features they plan to release into the developed branch, they'll create a release branch. The release branch is created by branching off of the developed branch. Once a release branch is created, there shouldn't be any new features added. But if you discover small issues with a feature already in the release, you can patch those features in the release branch. When the release is ready, the release branch will be merged into the main branch, which contains the production ready code. At this point, changes also need to be merged into the developed branch so that it contains any fixes made on the release branch. So that's how the entire workflow executes for a normal development cycle. But sometimes issues can arise that require a little more urgency. For that, you'll use a hotfix branch. A hotfix allows you to quickly patch a production release when something unexpectedly goes wrong. To create a hotfix branch, you'll branch off the main branch which will contain the production ready code. Then within this branch, you'll apply the fix for the critical issue, and then merge it back into the main and develop branches. That way the fix is integrated into both lines of development. That's the entire playbook for Git Flow. It's not too complicated, but there's a lot of branching involved, which creates some tension with continuous delivery practices. The work gets stored in those long-lived branches for longer periods of time, and that can delay integration of everyone's code.