It is by far the most popular version control system out there. In this chapter we will be looking at a plugin for gate called get flow, which proposes a branching model for software projects. This branching model doesn't offer much help when it comes to small projects, but medium size and large projects have a lot to benefit from it. We will be looking at a variation of the get flow plugin called lead flow avh which adds extra functionality like get hooks. To install it, we will follow the instructions on the GitHub page. We are on Ubuntu so we will follow the installation instructions for Linux.

We can see that it can be directly installed from a with the apt command but usually apt does not contain the latest version of the software. So today we will do a manual installation. We want to pick the stable version and use the one line command Let's create an empty directory and initialize it as a get repository. Basic get use it is not the purpose of this course, we are assuming that you understand the basics. A good way to get started with good flow is to read the excellent cheat sheet created by Daniel Kumar. This provides the basic tips and tricks to get you started quickly with a program.

So the first thing that he suggests is to run get flow in it. To configure it, we actually answer a bunch of questions about what names the branches should have in each flow. And what is the version tag prefix and hooks directory. Let's just leave the defaults in. All right, if we run get branch We can see that we are now on the developer side. So no more developing on the master branch.

This helps us have a stable master. While not so stable features are kept on the development branch. If we go back to the cheat sheet, we can look at the first item which is feature branch. feature branches are useful when developing a specific part of functionality, or doing refactoring. But you don't want to break the existing functionality on the develop branch. To create a feature branch, just run, get flow feature start feature one.

Now this is not the most intuitive description of the feature, but it's good for demonstration purposes. Good flow will also show us a summary of actions once the feature branch is finished. This has created a new branch called feature slash feature one based on this Develop branch and has switched us to that branch. We can also see this from our handy virtual prompt. Let's open up a file, edit and save it. It status.

This command will tell us that we have an uncommitted file. Let's go ahead and commit it. Now get committed using the nano editor for editing the commit message. Since we prefer vim, let's go ahead and change the default editor to be all we need to do is to add the sign in our shell config file and reload it. export the return equal view. Now when we do a git commit, vim opens up shows us a summary of the commit and closes.

Now let's assume that we are we finished adding feature it's time to merge the feature branch back to develop with get flow feature finish feature one. Again, to get the summary of actions, the feature branch was merged back to develop, then the feature branch has been deleted that the current branch will be switched back to develop. If we do a LS we see the file from our branch present on the develop branch. Looking at the cheat sheet, we see a graphical representation of this process. Next up is starting release. Release branches are good for stopping the incoming features and bugs bug fixes from the development and testing the current version, submitting bug fixes on it and releasing it to the general public.

As we can see, the syntax is similar the process is similar the Develop is branched to our list branch. And when it comes to finishing the branch, the features are also merged to the master branch and the tag is cut from this branch. Time to see it in action. Oh, okay, this switches us over to release slash 1.0 point oh branch. Let's add our release notes dot txt to show what has changed in this release. I added more bugs, hopefully not to let's commit the file.

This is usually the case when you start to run your integration and stress testing to see if all is good and no bugs were found. After the testing is finished, we go ahead and finish our release branch. is good will prompt us for a series of release messages where we will Go with the default. Checking out the summary we can see that the release branch was merged into Master, a tag was cut from Master with the release version. That tag has also been merged into develop, the release branch has been deleted. And we're back on the develop branch.

If we do a get branch, we see the only two available branches are master and develop. Get tag tells us that there is a 1.0 point oh tag cut. We can see that the branch now contains two files from the merge of the feature and release branch. And if you also switch to the master branch, we can see that at this point master is an exact replica of develop, get flow. One has more workflows than the ones presented. We won't go through all of them today.

You can get extra information by visiting the cheat sheet page or by reading the instructions on the GitHub page. Get flow also comes with an enhanced hooks functionality. If you read the documentation, we can see all the possible hooks in the hooks folder. Let's add a gate hook that will be executed before every hotfix branch. For this, we just opened the template, copy the content and paste it to a file with the name pre flow hotfix. Start in our hooks directory.

Let's just simply echo a message with the version and origin. If we look at the hotfix flow, we can see they are created from the master branch and merge back to master and develop with the tag on master. Let's try and see how it works. Apparently not something went wrong or script was not executed and we need to delete our branch. Then we just do our get flow hotfix delete branch analyzing the get hooks directory, we see that our hook does not have execute permission. After adding execute permissions and running the get hook command again we can see our message on the top of the hotfix output.

Let's finish this hotfix with get flow hotfix finished 101 Okay, as you can see the commands are pretty straightforward. There is also an Omi is a shell plugin that you can activate to have command line completion. As we said in the beginning, this is a plugin suitable for teams of developers working on multiple features fixing bugs, releasing hot fixes, all of these in the same time. Get flow is really simple to learn and helps teams have a correct To workflow where they can easily prepare patches for production code without worrying about the extra functionalities developed on the master branch. You can tweak the config as you like. Some people prefer to place the hooks folder in a different place so that it is committed on the heat rebel and they don't have to worry about copying the files over.

Others continue to develop on the master branch and use a separate branch like customer for the production code.