I'm using git for an iOS project, and so far have the following branch model:

 feature_brach(usually multiple) -> development -> testing -> master

Feature-branches are short-lived, just used to add a feature or bug, then merged back in to development and deleted. Development is fairly stable, but not ready for production.
Testing is when we have a stable version with enough features for a new update, and we ship to beta testers. Once testing is finished, it can be moved back into development or advanced into master.
The problem, however, lies in the fact that we can't instantly deploy. On iOS, it can be several weeks between the time a build is released and when it actually hits users. I always want to have a version of the code that is currently on the market in my repo, but I also have to have a place to keep the current stable code to be sent for release.

  • where should I keep stable code
  • where should I keep the code currently on the market
  • and where should I keep the code that is in review with Apple, and will be (hopefully) put on the market soon?

Also, this is a one developer team, so collaboration is not totally necessary, but preferred because there may be more members in the future.


1 Answer 1


I think that you should consider tagging master, when it is sent for release. If you try to match a branch to what is released, you probably will need to monitor the release date then quickly merge to the new branch. Since it is very manual, a tag should suffice.

One thing I like to do is upon release, perform a clone to a new repository. This is the "release" repository and can be setup with limited permissions. Your local repository would then have two remote repositories, so when it is time to release, you merge from one branch to another, then push the result to the release repository. Only you can do this last step and then others on the team can only have permissions to part of the workflow.

Not the answer you're looking for? Browse other questions tagged or ask your own question.