How to use git for iOS projects

When I’m working on a team, my preferred workflow is to use feature branches and pull requests with git. This comes largely from Scott Chacon’s article called GitHub Flow, though I’ve adapted it somewhat for iOS development.

  1. Anything in the master branch is good enough to build and send out to testers.
  2. To work on something new, create a descriptively named branch off of master (ie: fix-search or add-barcode-scanning).
  3. Commit to that branch locally and regularly push your work to the same named branch on the server.
  4. When you think the branch is ready to merge into master, create a pull request. (Not sure how to create a pull request? If you’re using GitHub, see creating a pull request).
  5. After someone else has reviewed and signed off on the pull request, you can merge it into master. (If you don’t know what to review in a pull request, check out How to review a pull request.)

If you read Scott’s article, you’ll note that I removed his point about how you can and should deploy master immediately after a merge. We do a new build of the app for our testers every week, so we just build from master and send it to our testers every Friday. In the iOS world, I think it makes less sense to build and deploy immediately after merging. For us, that would result in at least a build a day, and often multiple builds per day – and our testers need to download and install each one. To me, immediate deploys make more sense when you’re working on a web app – you can just deploy, and none of your users have to download or install the new version.

This flow works very well for us in our small 2-3 person iOS teams, and Scott says it works well for them on their 15-20 person teams. If you’re not using feature branches in git – and just committing everything to master – I’d highly recommend giving this approach a shot.