Take the 2-minute tour ×

I am using git and github, and I just finished the 1.0 version of my iOS app. From here, I am wondering how git can best serve me.

I really am just looking for a best practice here, and what others recommend for managing major versions.

Should I create a new branch for each new version, such as for 1.1, 1.5, 2.0, etc? Or should I just keep pushing to the master branch? If so, how do I do this?

share|improve this question

4 Answers 4

up vote 16 down vote accepted

I would recommend using tags (tag tutorial)

From your master branch since you are done v1.0 add a tag called v1.0.

git tag -a -m "Tagging release 1.0" v1.0

This way you can always come back to a specific version at any time by calling git checkout [tag_name]

Another common practice is to use branches to work on features until they are stable.

git checkout -b [feature-branch]

That creates a new branch named whatever is in [feature-branch] and checks it out. Be sure to do this from where you want to start working on the feature (typically from master).

Once stable they can then be safely merged into master. From master run:

git merge [feature-branch]

This way your master branch always stays in a working state and only completed items get added once ready. This will allow you to keep a working copy of the app at all times (ideally anyways) for testing, etc.

You could use branches for each version of the application however using tags makes it so you can't merge into another branch version by accident.

share|improve this answer
Agreed. Check in your 1.0 build and dsym files and add a tag. If in the future you're working on version 2.0 and discover that you need to release some change as 1.1 you can always create a banch from that tag. There's no need for a branch per release but you might want to merge your main development branch into a single release branch every time you make an ad hoc build so you hav a clear history of code released for testing vs unstable work in progress. –  Jonah Mar 23 '11 at 4:27
Ok, so once I add the 1.0 tag, how do I start working on 1.1? Do I set another tag? Confused about this concept. –  Nic Hubbard Mar 23 '11 at 5:18
To build on Jonah's comment, you only want a branch for a version if you are maintaining it separately. For example, if master is working toward version 3.0 but you find some bugs in version 2.0, you could create a maintenance branch starting from the 2.0 tag, eventually tag version 2.1 on that, and likely merge that branch into your master branch to get the bugfixes in the upcoming version 3 as well. –  Jefromi Mar 23 '11 at 5:20
@Nic: Think of it this way: master is what you'd release today if you had to. As soon as you tag and release 1.0 (master at that point in time), master becomes the branch working toward your next release. The version 1.0 tag sits back there in your history as a reminder of what you released, and possibly a branch point for bugfixes as I described a minute ago. If you're lucky, all it ever is is a reference. –  Jefromi Mar 23 '11 at 5:22
@Nic, Once you have tagged version 1.0 then just start coding for the next version. Once its done/stable then tag it as the next version (ie. 1.1). Repeat. As I mentioned above you may want to have a feature in it's own branch but that entirely up to you. No special commands or anything is required to start continue, just start coding. –  RDL Mar 23 '11 at 5:25

Personally, for large projects I've adopted most of the methods shown in this article:


It has worked out really well for me, and now there are even libraries and tools to help you follow along with the methodology: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

share|improve this answer

It depends on if you want to maintain older versions with bug fixes only. If you want to add bug fixes to 1.0 while adding new features to 2.0, you create a 2.0 branch, merge all bug fixes into both branches, and features into 2.0. But for each release within each branch all you need is a tag. Just remember to branch from the oldest branch you intend to merge back into.

share|improve this answer

You can also use the new GitHub releases mechanism. It is a way of managing software versions with GitHub.

share|improve this answer

Your Answer


