What is Gitflow

Git flow works with different branches to manage easily each phase of the software development, it’s suggested to be used when your software has the concept of “release”.

Below is the gitflow process in steps:

All features are developed on “feature/” branches (or otherwise prefixed, a common pattern when used with an issue tracker is to prefix with an issue number).
All pull requests are submitted to a common develop branch.
Generally a group of approved features is merged into develop and when they are all complete a release branch is made off of develop, prefixed with “release/”.
The release branch is tested, and any bug/regression fixes are merged directly into it.
At deployment time, this release branch is merged back down into develop and master, and a tag is cut. This tag is named with semantic versioning and becomes the latest release.
Any bugs/regressions found after the release is cut are dealt with using “hotfix/” prefixed branches, which are tested and merged in the same way as standard release/ branches.

Continuous Deployment

Idea is to push the feature as long as it is ready
So, potentially, you can have multiple deploys each day.
Benefit the client and obtain feedbacks faster
Reduce the # of features in each deployment – easier to manage
To achieve that, you need to have better tool and architecture

Is Gitflow fitting well with continuous deployment

Before you quickly draw the conclusion of it, lets try to do continuous deployment with gitflow. Here are the things we need to brainstorm:

We need to automate deployment if we can – No problem we can define a commit trigger that will execute our automated tests. Once all of them are passed, the build system can create a docker image and deploy it to our production environment. Wait, should we do that on dev or master branch? Continuous Deployment is more in favor of doing it on the branch that we frequently commit to. It looks like we should do that in dev branch. But in gitflow, we decide what to get out via creating a release branch out from dev instead of getting each commit in dev pushed. So, the concept of the release may need to rethink more for continuous deployment.
Can we do that daily? – That is not going to be easy as we have a bi-weekly sprint process and we commit to dev branch thru pull request. The process involves pull request, code review, automated test, cut a release branch from dev, test it in staging env, fix issues if we see, merge back to master and dev, tag the master and deploy the tag. The process takes time and it is not easy to do that daily as the overhead I just describe is not trivial. It is better bundle a set of tickets and release them as a whole. But for Continuous Deployment, each commit they want to automate the test. If passed, it will be automatically pushed out in production. The process is much lightweight and less in human decision.
How about doing it more than multiple times a day? – What? How can you get your feature out that fast? The overhead mentioned above makes once a day a challenge needless to say few times a day! At the end of the day, all tasks need to be fully done and tested at the minimum before getting it out right?

You may notice that GitFlow is not really fitting into the continuous deployment. In fact, Github is not using git-flow b/c it is practicing continuous deployment. The flow that Github is using called Github Flow.

Here comes Github Flow

The main concepts behind the Github flow are:

Anything in the master branch is deployable.
To work on something new, create a descriptively named branch off of master.
Commit to that branch locally and regularly push your work to the same named branch on the server
When you need feedback or help, or you think the branch is ready for merging, open a pull request
After someone else has reviewed and signed off on the feature, you can merge it into master
Once it is merged and pushed to master, you can and should deploy immediately

You can tell it is pretty much the same as gitflow with a major difference. What is that? Develop branch is gone!

Update 2016/06/19

Github has modified the flow a bit and now they deploy the feature branch after review directly to production before merge back to master.

Does gitflow work well with continuous deployment?