Phase 1: Mobile Fundamentals

Branching strategies for mobile release cycles

Beginner ~3 min read
Think of it this way A friendly analogy. Read this if the technical version feels dense. Show Hide

Imagine you're building a super cool LEGO castle. It’s a huge, amazing castle, and lots of your friends love playing with it. Now, you have a brilliant idea for a new secret passage and a magnificent new tower. But you can't just start ripping apart the existing castle to build them, right? What if you mess it up and your friends can't play with it anymore? And what if your new ideas aren't quite finished yet?

This is exactly how it works with building mobile apps, like games or other tools on phones and tablets. The app that everyone is using right now is like your amazing, finished LEGO castle. It needs to be stable and perfect. But you also want to keep building new things and making it even better. That's why we have different "building areas," which we call "branches."

First, you have the "main" castle. This is the version of your app that's already out there for everyone to download and use. It should always be super stable and ready to play with. Then, you have a big "planning table" where you gather all the ideas for the next big update. This is like your "develop" branch. When you have a brand new idea, like that secret passage or the new tower (we call these "features"), you take some LEGO bricks to a separate, small table (a "feature branch"). You build your new part there, all by yourself, without disturbing anything on the main planning table or the actual castle.

Once your secret passage or new tower is totally finished and tested to make sure it works perfectly, you carefully add it to the big planning table with all the other new ideas. You keep adding all the perfect new parts until the whole next update is ready. Then, just before you show the entire new castle design to your friends (or send the app update to the app stores), you set up a special "review table" (a "release branch"). Here, you make sure everything is polished and perfect one last time before it becomes the new main castle.

This way of building means that your friends can always play with a perfect, working version of your castle, even while you're busy building amazing new parts. It keeps everything super organized and makes sure nothing broken or half-finished accidentally goes out. So, when you're making your own awesome mobile games or apps, you can use these separate "building tables" to build big, exciting things without ever worrying about breaking what's already great!

For mobile app development, managing releases is a bit different from web projects due to app store review processes and the need to support multiple versions (e.g., the one users currently have, the one submitted for review, and the next big update). This is where branching strategies become incredibly valuable. Instead of everyone working directly on one main codebase, branching allows developers to work on new features or bug fixes in isolation. This prevents half-finished features from accidentally going live and ensures that your app's core, stable version remains untouched while new development is ongoing.

A common and practical strategy for mobile involves a few key branches. The main (or master) branch represents the code currently live in app stores or what's been approved and is ready for release. It should always be stable and deployable. For ongoing development of future features, you'll typically use a develop branch. New features are built on separate feature branches, branched off develop. Once a feature is complete and tested, it's merged back into develop. When it's time for a new release, a dedicated release branch is often created from develop for final testing and bug fixing before it's merged into main and submitted to the app stores. This workflow ensures that main is only updated with fully tested and approved code.

Another crucial branch type is the hotfix branch. If a critical bug is found in the live app, you can quickly create a hotfix branch directly from main, fix the issue, and then merge it back into main for an urgent patch release. This allows you to address immediate problems without having to wait for the next major release cycle, which might contain unfinished features from your develop branch. Adopting a clear branching strategy like this helps manage the complex lifecycle of mobile apps, ensuring stability, enabling parallel development, and streamlining the submission process.

Key Takeaways

  • Always keep your main branch stable, representing the currently live or approved app version.
  • Use develop for integrating ongoing new features and changes for the next major release.
  • Create feature branches for individual tasks or features, merging them into develop once complete.
  • Address critical bugs in the live app quickly using hotfix branches taken directly from main.
  • A structured branching strategy is essential for managing mobile app store review times and concurrent development.

Code Example

bash
# 1. Start a new feature (e.g., 'User Profile v2')
git checkout develop
git checkout -b feature/user-profile-v2

# (Work on feature... add files, commit changes)

# 2. Merge feature into develop (after review/completion)
git checkout develop
git merge feature/user-profile-v2
git push origin develop
git branch -d feature/user-profile-v2 # Clean up local branch

# 3. Create a hotfix for the live app (e.g., 'Critical Bug Fix')
git checkout main
git checkout -b hotfix/critical-bug-fix

# (Work on hotfix... fix bug, commit changes)

# 4. Merge hotfix to main (and then typically to develop too)
git checkout main
git merge hotfix/critical-bug-fix
git push origin main
git branch -d hotfix/critical-bug-fix # Clean up local branch

How this code works

This code example illustrates a practical Git branching strategy to manage ongoing feature development separately from urgent bug fixes in a mobile release cycle. It first shows how to handle a new feature, like 'User Profile v2'. The process starts by ensuring the development branch is current with git checkout develop, then creating and switching to a dedicated feature branch using git checkout -b feature/user-profile-v2. After work is complete, the feature is integrated back into the main development line by switching to develop and using git merge feature/user-profile-v2, sharing the updates with git push origin develop, and cleaning up the local feature branch with git branch -d.

The code then demonstrates creating a hotfix for a live app, such as a 'Critical Bug Fix'. This involves switching to the stable release branch with git checkout main, then creating a hotfix branch using git checkout -b hotfix/critical-bug-fix. Once fixed, the changes are merged directly into main using git merge hotfix/critical-bug-fix to quickly patch the live application, and git push origin main updates the remote. A key detail for beginners to note is that after merging a hotfix into main, these critical fixes should also be merged into the develop branch. While the example cleans up the hotfix branch locally, merging to develop prevents future releases from reintroducing the same bug.

Resources

Related Articles

Hand-picked reads to go deeper on git & version control for mobile.

Back to Mobile Developer Roadmap