I've been doing iOS development for a couple of months now and just learned of the promising CocoaPods library for dependency management.
I tried it out on a personal project: added a dependency to Kiwi to my Podfile, ran pod install CocoaPodsTest.xcodeproj
, and voila, it worked great.
The only thing I'm left wondering is: what do I check in, and what do I ignore for version control? It seems obvious that I want to check in the Podfile itself, and probably the .xcworkspace file as well; but do I ignore the Pods/ directory? Are there other files that will be generated down the road (when I add other dependencies) that I should also add to my .gitignore?
I commit my Pods directory. I don't agree that the Pods directory is a build artefact. In fact I'd say it most definitely isn't. It's part of your application source: it won't build without it!
It's easier to think of CocoaPods as a developer tool rather than a build tool. It doesn't build your project, it simply clones and installs your dependencies for you. It shouldn't be necessary to have CocoaPods installed to be able to simply build your project.
By making CocoaPods a dependency of your build, you now need to make sure it's available everywhere you might need to build your project...a team admin needs it, your CI server needs it. You should, as a rule, always be able to clone your source repository and build without any further effort.
Not committing your Pods directory also creates a massive headache if you frequently switch branches. Now you need to run pod install every time you switch branches to make sure your dependencies are correct. This might be less hassle as your dependencies stabilise but early in a project this is a massive time sink.
So, what do I ignore? Nothing. Podfile, the lock file and the Pods directory all get committed. Trust me, it will save you a lot of hassle. What are the cons? A slightly bigger repo? Not the end of the world.