How is 2 git branches workflow more convenient for mobile app development?

If you are a software engineer, you can’t avoid distributed version control systems like git in your coding projects, whether working in a team or solo. There are several workflows that engineering teams across the world follow. One of the popular workflows for small groups is keeping one long-running master branch for their mobile app development projects.

But, Is the master git branch slowing you down?

How often do you find yourself with bugs in your mobile app releases? It’s part and parcel of the software development lifecycle. You can not avoid these situations. Depending on the varying degrees of severity of such bugs, you decide to fix them and release such bug fixes. We followed a similar practice of keeping a master branch for our Android app development projects until we came across problems that were slowing us down.

Problems with a single long-running master branch

Having your git workflow on single master can lead to several issues like merge conflicts, inability to roll back changes, reduced productivity and increased risk of bugs. Following are the issues we struggled with before changing our workflow.

Problem 1: Releasing a patch

Imagine you and your team have just finished preparing a release candidate for your Android app development project, version 1.4.4. You’re excited to send it to QA for testing, but then you get some bad news: they found a bug!

The bug is in a new feature that the engineering team pushed after the release of candidate 1.4.4. So, to send a patch, you have to do the following:

This process is complex & time taking.

Problem 2: Releasing a hotfix

Let’s say you’ve released your app on the Google Play Store and you’ve received a report of a production issue. This is a serious issue, and you need to fix it as soon as possible. In this case, you’ll need to release a ‘hotfix‘.

A hotfix is a small update that is released to fix a specific issue. It is typically released quickly.

To release a hotfix, you will have to follow the steps mentioned in Problem 1. The only difference is that since you have released it on Google Play Store; the next release (hotfix) will be released with an upgraded version.

Problem 3: Difficulty in debugging issues

When we get a production issue, the first thing we do is identify the app version where the issue is occurring. We can do this by looking at the crash logs or by talking to our users. Once we know the app version we can use the stack trace to find the line of code where the issue is happening. However, to reproduce the issue in the development environment, we need the exact copy of the code which was packaged for the release. Finding the exact release commit is hard to find in a master only git workflow.

Problem 4: Lack of a reliable code version history

Another problem is that you will sometimes be required to know what changes were made to a file or piece of code in different app versions. This can be difficult because the release commit is not visible in the version history of the file. Therefore, the only way to determine which commit was part of which release is to look at the date of the commit.

Solution overview

Instead of using a single long-running master branch, you can use two long-running branches:

1. master: This branch is used for development.
2. release: This branch is used for releases only.

Following is an example that illustrates how this approach will eliminate the problems we discussed above.

Prepare for a release

Let’s assume you are preparing a release candidate 1.4.5. When you are ready to release this version of your app, you will do the following:

1. Commit the updated code that contains the scope of 1.4.5 in the master branch.
2. Update the version number in the Gradle file.
3. Squash Merge the master branch into the release branch.
4. Release the app to QA and internal testing.
5. Continue development on the master branch.

Solution for releasing a patch

If QA finds an issue in internal testing, you will do the following:

1. Create a temporary branch called patch-1.4.5 from the release branch.
2. Commit changes to fix the issues that QA found.
3. Squash merge the patch-1.4.5 branch into the release branch.
4. Cherry-pick the patch commit into the master branch and resolve any conflicts that occur.
5. Delete the patch-1.4.5 branch.
6. Build from the release branch and release the app to QA again.
7. Repeat steps 1-6 until the app passes QA tests.
8. Release the last build on the Google Play Store and tag the last commit on the release branch with the version code 1.4.5.

Solution for releasing a hotfix

For a hotfix, we will repeat the same process as a patch release, with the following differences:

• The temporary branch name will be hotfix-1.4.5.
• We will change the version name and code in the Gradle file.

Solution for debugging issues

To debug issues, you can use the following steps:

1. Checkout the release branch.
2. Reset the HEAD to the git tag or commit message corresponding to the app version where the issue is occurring.
3. Debug the issue.

This will give you an exact copy of the code where the user is experiencing the issue.

Reliable code version history

To see the history of a file release-wise, you can refer to the release branch. The git history of that file will only show release commits.

For example, if you want to see the history of the file MainActivity.kt release-wise, you would checkout the release branch and then view the git history of the file. The git history would show you all of the commits that were made to the file for each release.

This can be helpful for debugging issues or for understanding how the file has changed over time.

Conclusion on using a separate release branch

Using a separate release branch can improve the agility, debugging abilities, robustness, and productivity of the development team.

1. The master branch contains all of the commits that the engineering team has made, but they are not in sequence of release.
2. The release branch contains only the commits that have been released, both internally and to production.

This separation of branches allows the development team to be more agile. They can make changes to the master branch without affecting the release branch. This makes it easier for the team to experiment and try new things.

The separation of branches also makes it easier to debug issues. If an issue is found in a released version, the team can quickly find the commit that introduced the issue by looking at the release branch. This makes it easier to fix the issue and release a fix.

The separation of branches also makes the development process more robust. By having a separate branch for releases, the team can protect the release branch from changes that could introduce errors. This makes it less likely that a release will be buggy.

Finally, the separation of branches can improve team productivity. By having a separate branch for releases, the team can focus on developing new features and fixing bugs without worrying about affecting the release branch. This can free up the team to be more productive.

You can check our post on utilising BitBucket pipelines and AWS CodeDeploy for maximising CI/CD efficiency.