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.
- Anything in the
masterbranch is good enough to build and send out to testers. - To work on something new, create a descriptively named branch off of
master(ie:fix-searchoradd-barcode-scanning). - Commit to that branch locally and regularly push your work to the same named branch on the server.
- 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).
- 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.