Why your App team should follow a defined Git workflow

Prerequisite/definitions;

Git – Version control system

Branch – A specific version of your code

Merge – The act of combining changes in one version of your code with another

Commit – A set of changes to a version of your code

Tag – A specific point in version history (commit)

By using a well known and battle tested workflow, your team will know how to handle any situations that might arise in a project and keep everyone on the same page.

The workflow should help your dev team maintain speed and quality, and should work to support other roles in your organization too. Testers and configuration managers, but also project managers and project owners will benefit from a well defined workflow.

GitFlow is one of the many possible Git workflows to use in a development team. It’s well defined and flexible enough to accommodate various teams sizes and slightly different ways of working.

With GitFlow you’re working with two perpetual branches; master and develop. And multiple

short lived branches of feature- and release-types.

Master branch

Your master branch is the version or your code that is in production. Nothing goes into the

master branch until it’s deployed. Having a separate branch for production code makes it very easy to be absolutely sure what code is live, and which code has not yet been deployed into production.

Develop branch

The develop branch is what’s expected to go into the next release. Changes are not made directly to the develop branch, but each change or addition is made in a separate feature-branch which is then merged into the develop branch. In fact; it might be a good idea to configure your repository to not at all allow commits to master and develop branches, only allow merges.

Feature branch

These are the branches that developers work with on a daily basis. Feature branches are normally created (branched) from the development branch to add new functionality to the upcoming release. How long feature branches live, and how large they become, depends on your team’s methodology. Which in turn might be affected by its size and testing procedure.

But it’s normally a good idea to not let feature branches live for more than a couple of days.

Ideally not even a day. Short lived feature branches limit the work needed to merge the branch, and resolve potential conflicts, with the work done from other developers on the develop branch. How you’re working with feature branches depends a bit on whether you’re striving for Continuous Integration, or if you’re fine with merging completed features in bigger chunks. But this is a topic for another day.

Release branch

When it’s time to release a new version of the code, GitFlow mandates that we branch from develop to create a release branch. The release candidate can then be quality assured. Any fixes needed are done in the release branch. Development on releases further in the future can proceed on the develop branch without affecting the upcoming release. If the release schedule changes during this time, we still have a tested version of our code ready for deployment at any time.

Releasing a new version of your App

When we’re happy with the release-candidate and want to push it into production, we first tag the release with a version number to be able to know exactly what went into which version of our code. The release branch is then merged both back into develop and into our master branch that now holds the version of the code we’ve just released.

Hotfix branch

Sometimes problems are found in already released code. To fix such problems, GitFlow allows us to create a hotfix branch from master where the problem can be fixed. We can then release the fix without having to take into account any work that has been done on the develop branch. Remember that when the fix is done, the hotfix branch has to be merged both into master and into the develop branch to avoid the problem remaining in the next version released.

Summary

As mentioned in the beginning, GitFlow is just one possible way of working with git. But it’s worth following a well defined workflow to have a clear and joint idea on how each step in the development process should be handled.

GitFlow benefits in App development

• Battle tested workflow with lots of support in tooling and documentation.
• Well suited for code reviews.
• Suited for automated test, build and deployment flows.
• Clear release and development process makes quality assurance easier.
• Explicit version history makes bug fixes on released code possible.
• Work on the upcoming release and future releases can be done in parallel.