-1

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.
So:

  • 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.

gnat
  • 21,442
  • 29
  • 112
  • 288
charleyh
  • 99
  • 4
  • possible duplicate of [As a sole developer (for now), how should I be using Git?](http://programmers.stackexchange.com/questions/114258/as-a-sole-developer-for-now-how-should-i-be-using-git) See also: [Git for a solo developer](http://programmers.stackexchange.com/questions/209401/git-for-a-solo-developer) – gnat Aug 27 '13 at 23:20

1 Answers1

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.

sleeves
  • 111
  • 1