fbpx
September last year(2015 I released my iOS app, My Day To-Do and the following December I released the Lite(free) version, which is missing a few features from the paid version. At this point, both versions have a different code base i.e. seperate repositories and when I add a new feature to the either of them, I basically copy and paste the code from one place to the other. I know this method is horribly prone to errors, right? well, I wanted to release the Lite version just before Christmas and since I started working on it a week or two before the holidays, I could not afford to invest time into finding out best way to go about it. However now that I plan to release another paid but limited and cheaper version of My Day To-Do, I am thinking of doing it right this time. 

Introduction

Since 2013 my version control of choice has been Git and I have used it on all my projects ever since including My Day To-Do family of apps. I always knew about branches in Git but I only ever used it for testing some new features before they are ready to be merged into master. Now the more I think about branches the more I think maybe I could simply use that for my versioning problem i.e. a branch represents a version of my app. 

Solution

Understanding the basics of something is always important, ok let’s try looking at this with an example. Say I wake up one morning thinking that it’s time I get in shape and look like a certain thunder god! What would I do? Naturally I would go to the gym and start working out. Say this is the first time I am going to the gym, I will start with lighter weights and increase weights as I get used to it. I will keep doing it and in time, I will have muscles to rival that of a thunder god! Right? ok maybe not, but the point of that example is that I want to get used to the basics before I advance further. Similarly when I want to learn a new way to do solve a big problem, I start by creating and solving a smaller version of that problem. This way I understand the fundamental building blocks of the solution. So without further a due, let’s get started with solving a simple problem.

Scenario

We are building an awesome hybrid mobile app with awesome features. 

Project setup

Create a folder and call it appHomeDir and within that folder create two html files called index.html and about.html respectively.  Here’s what the files look like,
index.html

<html>
<script>
function showAwesomeFeature() {
window.alert("It can show pop-ups");
}
</script>
<body>
<h4> Awesome app </h4>
<p><a href="about.html"> About Creator </a></p>
<button onclick="showAwesomeFeature()"> Awesome feature </button>
</body>
<html>

about.html

<html>
<body>
<h2> Created by Bhuman soni</h2>
<p>
<ul>
<li><a href="http://captaindanko.blogspot.com.au/"> Author of Bhuman's programming diary </a> </li>
</ul>
</p>
<a href="index.html"> Home </a>
</body>
</html>
Great now let’s navigate to appHomeDir in the command line. Terminal on a Mac or a Linux machine or Git bash or so on a Windows machine. 
Initialise a Git repo by running git init
Start tracking our html files by git add about.html index.html 

Commit the code with git commit -m “initial commit”

Now we can release our awesome app to the public

A new version of the app

On releasing the app, we realise that our app is a bit too popular and we have had over 1 million downloads on the first day (yup the app we made is that awesome). At this point we realise that we can piggyback on the success of our awesome app and release another version of it. So we call it Awesome App Pro and it would be like our original app but have 3 awesome features instead of 1. 
Since it is just another version of our original app, we ideally want to reuse the code we have already written. So navigate to the folder(appHomeDir), 
Create a new branch – git branch awesomeAppPro

Checkout the branch – git checkout awesomeAppPro

We are now on awesomeAppPro(Pro) branch i.e. the code base for the pro version of our app.

Adding new features to the Pro version

Now that we are on the Pro branch let’s start adding out extra features. We add awesome feature no 2  which is showing that the app can multiply numbers and our index.html file looks like this,

<html>
<script>
function showAwesomeFeature() {
window.alert("It can show pop-ups");
}
function doMath() {
window.alert("It can do Mathn3 X 2 ="+2*3+".");
}
</script>
<body>
<h4> Awesome app </h4>
<p><a href="about.html"> About Creator </a></p>
<button onclick="showAwesomeFeature()"> Awesome feature </button>
<button onclick="doMath()"> Awesome feature 2 </button>
</body>
<html>
Just as we are about to add awesome feature no 3, we get some feedback from our user that the app name is not very clear to them and they are wondering if we can do something about it. As you can see in the code for the index.html file our app name i.e. Awesome app is with h4, so perhaps the solution to the problem would be to simply change it from h4 to h1. Now remember the app name is common across both versions of the app so whatever change we make must apply to both versions. First things first lets give our users what they want,
Save the work in the Pro branch – git add index.html && git commit -m “added awesome feature 2”

Checkout master branch – git checkout master
Apply the fix to index.html and commit – git add index.html && git commit -m “name size fix”

And we have made our users happy by giving them a fix that they asked for. Working on the Pro branch we notice the About page could use some more info about the author. So we modify the about.html file and add some info about the author’s iOS app, after which the about.html file looks like this

<html>
<body>
<h2> Created by Bhuman Soni</h2>
<p>
<ul>
<li><a href="http://captaindanko.blogspot.com.au/"> Author of Bhuman's programming diary </a> </li>
<li><a href="www.mydaytodos.com"> Lead developer at My Day To-Do </a> </li>
</ul>
</p>
<a href="index.html"> Home </a>
</body>
</html>
Commit all the code – git add about.html && git commit -m “added more author info” 

Merging changes across versions

Remember the app name is common across both versions so the change that we just added to the master branch i.e. released version must also be applied to the Pro branch. Fortunately this is very easy in git, let’s see how we can do this,

Checkout the Pro branch – git checkout awesomeAppPro

Merge the code from the pro branch – git merge master

Git will prompt to write a commit message for the merge, so for this we will just say something like
Merge code from master and done the awesomeAppPro branch has our fix for name size and we can continue working on our feature. 

Overwriting files between versions

In the above example the merge process also merged the code for about.html. 
Git merge tries to merge the changes across all the files in the branch while this is the way to go in most cases, there could be a scenario where we may only want to get the latest code for a particular branch. For example, in the aforementioned scenario, the index.html maybe rightfully different between the master and the pro branch where the about.html maybe the same across both branches. Now in this case if we update the about.html in the master branch, we simply want to update the about.html in the Pro branch without touching the index.html. If we try to do a merge(master with Pro) it will not only update the code in about.html but it will also try to merge the code in index.html which will result in a merge conflict and that is something we want to avoid in this case. What we want here is to simply get the latest code from the about.html file in the master branch without touching index.html. So how are we going to solve this? 
The Git cherry-pick command does come to mind, but I found another solution thanks to this very helpful blogpost that could solve our problem quite easily. 
To only get the code from the about.html from the master branch, while in Pro branch,
Get the latest code for about.html by – git checkout master about.html

In summary 

In this post we covered some of the fundamentals of how to use the same codebase for two different versions of your app via branching in Git. Of course in this post I built a solution with a small code base and when I start using this in my app (My Day To-Do), I may run into many problems one of which maybe a merge conflict. Therefore I will either update this post or write a new post where I talk about the solutions to some of those problems.
Until then, hope you learn something from this post and I really am looking forward to applying this method to the next version of My Day To-Do. If you know of a better way to work off the same codebase for different versions an app, please leave me a comment.
Ohh and how did I learn about this? Well a bit thanks to the Git Docs, some of the best documentation I have come across.

Finally, I am working on my app full-time right now so if you find my blog posts useful and want to support me you can 

  • Or one of the cheaper versions, L or W

You could also show your support by giving the My Day To-Do Facebook page a like.


Leave a Reply

Your email address will not be published. Required fields are marked *