Archive for the ‘git’ Category

Automatically increasing versionCode with Gradle – Followup

Wednesday, February 12th, 2014

This article is a followup to the original that can be found here.

As a normal use case the original article provides a good way not to worry about increasing the version number. The only drawback is that the number is really increased every time you compile the source code. This results in jumping versionCodes in the commit history. For instance lets say you checked out the App with the versionCode set to 3. After compiling the application for several times, until you deem it stable, you might check it in with a versionCode of 15. It would be more desirable to increase it just by one.

To achieve this we are going to base our new implementation on the committed state of the AndroidManifest.xml (here for the DriveNow project).

To incorporate this into the normal build process, we can basically use the same methodology we used in the original version. If we want to go a step further and don’t increase the version if we are running on our integration server, we can also alter the task definition a little bit.

Running the build now with  ./gradlew assemble -D buildConfig.keepVersionCode=true will build the project without increasing the versionCode.

Useful things when working with git

Wednesday, November 27th, 2013

So you’re working with git and you think it’s the best thing that every happened to you? Same with me, however there are a few settings that make working with git even more fun! Here they are:

This will always assume you want to push you current branch to origin with the same name (like develop to origin/develop).

More or less the same thing, just in the other direction. When you pull, git will assume you want to fetch & merge the origin branch with the same name.

This will disable fast-forward when doing merges. This means, that even if there is no merge needed (because one of the parents is the common ancestor), there will still be a merge commit. This is useful to keep track of the branch history.

This will tell git to use style diff3 to solve conflicts. Compared to the default style, this will also add the common ancestor version in the conflicting file, showing not only the result in both branches, but also the state before the changes. This often helps to resolve conflicts easier.

This tells git to remember how you solved a conflict. When a conflict appears, git will check the conflict history database and uses the same solution if the conflict is the same. Very helpful if you have conflicts that appear again and again (like storyboard files or submodules).