Releasing an app update on Google Play

Briefly recording my workflow for releasing an update for the Commons app on Google Play (lest I forget!):

  1. Submit pull request with my changes to project maintainer. Wait for merge.
  2. After pull request accepted, do versioning and tagging
  3. Record changes in file
  4. Generate a signed APK using the keystore file, keystore password, key alias (auto generated by IntelliJ) and key password
  5. Upload new APK to Google Developer page and copy over changelog to be shown to users
  6. Wait several hours for the update to go through, then check app to see if it works as intended
  7. Do git rebase upstream/master to update my repo based on the upstream repo without creating messy merge commits. Check what the upstream repo is via git remote -v if there are errors with this.
Releasing an app update on Google Play

Git revert, git reset, and git checkout

A nice summary on the differences between git revert, git reset, and git checkout by

git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the –hard option. If you want to extract specific files as they were in another commit, you should see git-checkout[1], specifically the git checkout — syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory.

And an article by Atlassian:

Git revert, git reset, and git checkout

Commit early, commit often!

Today I learnt that:

1) I will be spending an extra hour having to re-do something, because I made the silly mistake of bundling several changes into one commit. Turns out that commit might be buggy, and because it’s so ridden with multiple changes it’s difficult to pinpoint any causation. Hence a revert of the entire commit…

2) There really is no downside to committing all the time because you can revert any commit at any time and still keep all the commits that were made after that (as opposed to having to revert in linear fashion).

Commit early, commit often!

Versioning and tagging

The project maintainer of the open source Android app that I’m contributing to (Upload to Commons) has given me developer access to the app on Google Play! Exciting stuff. 😀 While I’ve tinkered with Android before, none of the apps I made have ever made it to the store. I don’t think I’ve even paid for a publisher account yet (note to self: this must be remedied in the future).

I’ve learnt real quick that maintaining a live app on Google Play is quite different from just tinkering on an app that isn’t in use by real people! The user base for this app is currently still small, so fortunately there’s no need for running a beta test and such. But one of the things it does require is managing the version so that the updates make sense and are tidy. There are two places this needs to be done…

The Android Manifest

In the <manifest>  element of the AndroidManifest.xml file, the values that need to be changed are:


The android:versionCode attribute is the internal version code that isn’t displayed to the user, and is used to determine which version is more recent, so we just increment this by 1 for each successive version. The android:versionName attribute is used solely to display the version to the user, and in our case we will increment it by 0.1 for each successive version.

Tagging the relevant commit in Git

I found a useful blog post on the use of git tag.

Basically, I go into the shell (yup, this has to be done via command line AFAIK) and, if I want a lightweight tag, type

git tag v1.3

If I want an annotated tag, I’ll type

git tag -a v1.3 -m "Version 1.3"


Tip of the day: Found out from my mentor that adding ?w=1 to the end of the URL for a particular commit on GitHub (e.g. makes it ignore the file changes that just involve whitespace! Whew.

Versioning and tagging

Git (and GitHub) for newbies

I confess: I have a love-hate relationship with Git. I signed up for a GitHub account back in 2013 during college when I heard that it was all the rage among the cool coder kids… and never got around to using it. The command line was too bloody intimidating, and what was all this push pull merge branch stuff?

So I am ashamed to admit that spent my college and postgraduate days doing my own ‘version control’ by saving a billion copies of “Assignment_final”, “Assignment_final2”, “Assignment_final_for_real” on multiple devices and Google Drive (funny thing is, I wasn’t the only person in my class who did this, not by a long stretch). It was incredibly inefficient and downright stupid. I would’ve saved heaps of time if I’d invested some up front in learning Git.

This year, I finally made myself dig in my heels and commit to learning Git and by conjunction, GitHub (as I understand it, Git is the version control system and GitHub is the hosting service for Git repositories). I gritted my teeth, armed myself with a bunch of tutorials, and plunged into the unknown.

After a good deal of frustration, I managed to get some of my old coding projects up as repositories on GitHub. Shortly thereafter, I decided to apply for an Android development project in the Outreachy Dec ’15 program, which, surprise surprise, involved the use of GitHub for collaboration. Several bugfixes later, I think (or would like to think) I’ve finally gotten the basics of Git(Hub) down.

I noticed that a lot of the tutorials I found were extremely theoretical, which is good for someone who already has a basic grasp of Git and really wants to understand how it works under the hood, but not so good for someone who is completely new to it. The website itself has a mini ‘getting started’ tutorial, which is pretty good, but it omits some important things IMO.

So I figured I should share my little Git(Hub) tutorial, partly for my own sake (I have a terrible memory!) as well as to hopefully help fellow Git(Hub) newbies.

First things first…

You don’t need to know command line to use the basics of Git(Hub). There are lots of people who manage their repositories solely by command line, but you don’t have to if you don’t want to. My main tools for managing my GitHub repositories are:

  • The GitHub desktop client
  • – the website where you can browse your own repositories and those of others. Your repositories are linked to your GitHub page. For instance, my GitHub page is and the repository I’m working on currently is

Sign up for an account at Download and install the GitHub desktop client. Now you are ready to start working on a repository.

Forking a repository

If you are contributing to open source, this repository likely already exists on someone else’s GitHub page. Go to that page and fork their repository. That will create your own repository that is a copy of the upstream repository. In my case the upstream repository’s URL is and my forked repository’s URL is

Next, click the ‘Clone in Desktop’ button on the right hand side of your own repository page. This creates a local copy of the repository on your hard drive. Now you have 2 copies of your repository, the local copy (also called working copy) stored on your machine, and the remote copy (also known as the origin) stored online.

Building the project and setting up your VCS

GitHub repositories usually consist of uncompiled code, so you need to build the project once you have cloned a local copy of it. To do this, follow the instructions on the of the upstream repository (scroll down on the main page to view this readme file). If your project has no build instructions, talk to the owner of the project.

Once you have built your project, you need to hook that project up with Git (I don’t think cloning in and of itself creates a link). Open the GitHub desktop client and drag the folder containing your project into the client. Follow the steps in the wizard and voila, your local copy is powered with the Git version control system and ready to go.


Before you make any changes to the code, create a branch. You do this by clicking the branch icon at the top of the desktop client and naming it. Now all your local code changes will be saved to this branch.

You can have multiple branches in your repository, and the default branch is called master. Normally you work on a certain feature or bug in one of the other branches (not in master). Later on you can merge branches back into master.


Once you have made a change to your code, you can commit it. This saves a snapshot of your code at a point in time to your remote repository (aka origin). If you set everything up correctly, your desktop client should automatically detect changes in your project folder (make sure you are in the ‘Changes’ tab). So committing is as simple as typing in a description of your code changes, and clicking commit.

An important thing to note is that you should commit in small, modular amounts. Don’t save everything for one large commit. The reason for this is that you can easily revert a commit (by clicking ‘Revert’ in your desktop client), but you cannot easily revert half-a-commit if you want to keep some of the changes you made and discard the rest. An interesting thing to note is that reverting a commit creates another commit in the project history. So everything you do is recorded. 🙂

Merging/submitting pull request

Once you are satisfied with your code changes, you have 2 major options.

    1. You are working alone, or not yet ready for your code to be pulled into the upstream repository but you are done with this bugfix/feature and want to work on another. In that case you should push the changes to your remote repository (by clicking ‘sync’ on the top right of the desktop client), then merge your branch with master.
    2. You are ready for your code to be pulled into the upstream repository. In this case you want to submit a pull request to the upstream repository. Click ‘submit pull request’ in the desktop client.

Also, if you are fixing a particular issue that has already been recorded in the ‘Issues’ list in the project page, type something like ‘fixes issue #4‘ in your pull request description. This automatically links your pull request to the issue.

If the owner of the upstream repository thinks your code is okay, he/she will merge your pull request into the upstream repository, which means that your code is now part of the upstream repo! Once that happens you should also merge your branch into the master branch of your own repo.

Keeping up to date with the upstream repository

There are multiple ways of doing this, but this is the simplest. In your desktop client, click ‘Update from upstream/master’. This pulls all of the changes from the upstream repo into yours. Be aware of which branch you are pulling from and into.

Using the command line

Occasionally, you will still need to use the command line for stuff that has not yet been incorporated into the desktop client. Click on the cogwheel and ‘Open in Git Shell’. This opens up a command prompt with your path already set to the project folder. Hooray, no need for cd-ing around!

So, these are some of the things I’ve learnt from my short stint with Git. 🙂 This learning is obviously still a work in progress, so feel free to comment and correct anything that needs correcting.

Git (and GitHub) for newbies