A git workflow for the app store submission process

When you submit an app to the app store for review, what do you do?

Do you simply stop development on the app until the review comes back? Do you keep working on new features? If your app is denied, do you try to resubmit it with the new features you added since the first submission? Do you try to undo everything you did, fix the issues found in the review, and resubmit? Do you switch over to another app?

The app store review process causes some interesting workflow challenges, but git makes them easy to deal with.

Let’s assume that you’re already using Git and Dropbox (or some other DVCS such as mercurial, and some other form of backup or a networked repository). If you aren’t, you should be, so stop reading this article and go read this one instead.

Let’s also assume that you are familiar with basic DVCS concepts such as branching, merging, and tagging. If you aren’t, the git book is a great place to learn.

So, we are ready to start working on some cool new features. We’ll start by creating a branch for our next version – in this case, version 1.3.

Martys-Mac:WhichEpisode marty$ git checkout -b 1.3
M	Which Episode.xcodeproj/project.xcworkspace/xcuserdata/marty.xcuserdatad/UserInterfaceState.xcuserstate
Switched to a new branch '1.3'

Now we’re ready to make our changes. We’ll fix a few bugs, add some features, tweak some views, and so on. This might take a few commits – that’s totally fine.

...make changes...
git commit -am ...

...make changes...
git commit -am ...

...make changes...
git commit -am ...

Ok, we’re now done version 1.3, and we’ve uploaded the binary to the app store for review. Time to end our work on the 1.3 branch by merging it back in to master, and then pushing our changes to our repo in DropBox. You can also push to your remote repo for safekeeping at any point during development of 1.3, of course.

Martys-Mac:WhichEpisode marty$ git checkout master
Switched to branch 'master'
Martys-Mac:WhichEpisode marty$ git merge 1.3
Updating 41988bd..90adff4
Fast-forward
 Default-Portrait@2x~ipad.png                       | Bin 0 -> 18121 bytes
 Default-Portrait~ipad.png                          | Bin 0 -> 5949 bytes

Martys-Mac:WhichEpisode marty$ git push
Total 0 (delta 0), reused 0 (delta 0)
To /Users/marty/Dropbox/Projects/WhichEpisode.git/
   41988bd..90adff4  master -> master

At this point, the branch for 1.3 is still there, but we won’t need to touch it again unless something goes wrong with our submission. However, we are ready to work on our next release, 1.4, so let’s create another branch for it:

Martys-Mac:WhichEpisode marty$ git checkout -b 1.4
Switched to a new branch '1.4'

You can now start working on all the cool new features for your next release.
If 1.3 gets rejected, and you need to apply a fix to it, just switch to the 1.3 branch, make the change, and commit it.

Martys-Mac:WhichEpisode marty$ git checkout 1.3
Switched to branch '1.3'

...fix bug...
git commit -am ....

Re-submit the binary, then switch back to the 1.4 branch and merge in the change, to make sure it stays up to date with any important fixes.

Martys-Mac:WhichEpisode marty$ git checkout 1.4
Switched to branch '1.4'
Martys-Mac:WhichEpisode marty$ git merge 1.3
Updating 90adff4..3152f6d
Fast-forward
 0 files changed
 create mode 100644 test.txt

Astute readers may notice that at this point, we have a change in the 1.3 branch that’s not in master. I can live with that, because I know the change will find its way to master once the 1.4 branch is merged, but if you are really worried you can always merge 1.3 to master again.

Martys-Mac:WhichEpisode marty$ git checkout master
Switched to branch 'master'
Martys-Mac:WhichEpisode marty$ git merge 1.3
Updating 90adff4..3152f6d
Fast-forward
 0 files changed
 create mode 100644 test.txt

So, that’s pretty much how I use git to work with the app store release process. It lets me submit releases to the app store for review, and then continue development in another branch, without worrying about what to do if my app gets rejected.

This has been working quite well for me, but I am curious as to what everyone else does. Thoughts? Ideas? Ways to improve the process? Do something completely different? Use git-flow? I would love to hear your stories!

5 Comments

  1. [url=http://www.bestevance.com/rolex/Cellini/index.htm]鋼のや金のバージョンがとても類似しているので、私は彼らが両方ともである性質のいくつかを議論するのを許します。第1のケースのサイズは、古典的なオメガスピードマスタームーンウォッチスタイルの場合には適度の39.7mmワイドである。オメガ・ブラウンのストラップで彼らとペアを選びましたが、この場合において、白のコントラスト縫い目による美しいマットアリゲーターストラップ。ちょうど下の40 mmのワイドで、この服装腕時計のようにたくさん着、フォーマルな服装と長いそでのために良いことだが、その古典的な観察を絶え間なくオメガスピードマスターがまだあります。[/url]

    Reply

  2. [url=http://www.newkakaku.com/gjb1.htm]スーパーコピーロレックス,スーパーコピーロレックス時計通販スーパー コピー品その他の世界一流ロレックススーパーコピー時計品を扱っています。ヴィトン コピー、ヴィトン コピー 激安(N品)専門店”[/url]

    Reply

  3. [url=http://www.ooobag.com/watch/franckmuller/tonneau/6df2d4b8c64fb4c0.html]より高い終わり時計に適した、このように、ストラップサントーニの贅沢な靴屋によって作られています。これはいくつかの高品質の結果(臭い)が使用されている革。 シャネルスーパーコピー ステンレス鋼のモデルは、黒い革のバンドを特徴とします、赤い金の反復は、茶色の革のひもの上に来ます。あなたの黒い革のひもを得るならば、それはdeployantは、茶色のストラップが標準的な香りバックルを特徴としながら(レッドゴールドでではあるが)。[/url]

    Reply

  4. [url=http://www.ooobrand.com/about/index.html]バセロンコンスタンチン(Vacheron Constantin)「花たゆう時光」時計芸術テーマ展が上海ヴァシュロン・コンスタンタンの家の開幕。バセロンコンスタンチンからジュネーヴ博物館の花卉芸術骨董表、金や最新の花の神殿シリーズの腕時計、Cartier時計コピー完璧な融合タブ工芸と花卉芸術表現タブ大師の好プレーとアイデアの夢。有名な時計収蔵下僕にさんも現場へ。[/url]

    Reply

  5. [url=http://www.gowatchs.com/brand-199.html]の原則は原則の詩と経済学の原則で、第2の「等価。ここでは、まあposited実用方程式の間です。「いい」、「次」と「既成事実」。PAS(良いと深刻な自制、自制、自制)。」準配備本もろくて弱い経済方程式、探求の境界の間の過程と製品、成功と失敗、天才と。ロレックス 時計コピー「なくて、私達のここだけの話しましょう、私達に引き続き気づいた、このタイプの反復件1。[/url]

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *