What goes into your .gitignore if you're using CocoaPods?

Question

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 person

Answer 1

I prefer committing Pods directory along with Podfile and Podfile.lock to make sure anyone in my team can checkout the source anytime and they don't have to worry about anything or do additional stuff to make it work.

This also helps in a scenario where you have fixed a bug inside one of the pods or modified some behaviour as per your needs but these changes will not be available on other machines if not committed.

And to ignore unnecessary directories:

xcuserdata/

Answer 2

Pros of not checking in Pods/ to version control (in subjective order of importance):

1. Much easier to merge commits, and review code diffs. Merging is a common source of issues in a code base, and this allows you to focus only on things that are pertinent.
2. It's impossible for some random contributor to edit the dependencies themselves and check the changes in, which they should never do (and again would be hard to identify if the diff is massive). Editing dependencies is very bad practice because a future pod install could occlude the changes.
3. Discrepancies between the Podfile and the Pods/ directory are found quicker among teammates. If you check in Pods/ and, for example, update a version in the Podfile, but forget to run pod install or check in the changes to Pods/, you will have a much harder time noticing the source of the discrepancy. If Pods/ isn't checked in, you always need to run pod install anyway.
4. Smaller repo size. Having a smaller byte-footprint is nice, but that doesn't matter much in the grand scheme. More importantly: having more things in the repo also increases your cognitive load. There is no reason to have things in the repo that you shouldn't be looking at. Refer to documentation (the abstraction) to know how something works, not at code (the implementation).
5. Easier to discern how much someone contributes (since their lines of code contributed won't include dependencies they didn't write)
6. JAR files, .venv/ (virtual environments), and node_modules/ are never included in version control. If we were completely agnostic about the question, not checking in Pods would be the default based on precedent.

Cons of not checking in the Pods/

1. You must run pod install when switching branches, or reverting commits.
2. You can't run a project just by cloning the repository. You must install the pod tool, then run pod install.
3. You must have an internet connection to run pod install, and the source of the pods must be available.
4. If the owner of a dependency removes their package, you are in trouble.

In summary, not including the Pods directory is a guardrail against more bad practices. Including the Pods directory makes running the project easier. I prefer the former over the latter. You won't need to debrief every new person on a project about "what not to do" if there is not a possibility for making certain mistakes in the first place. I also like the idea of having a separate version control for the Pods which alleviates the Cons.

Answer 3

I'm in the camp of developers who do not check in libraries, assuming we have a good copy available in another location. So, in my .gitignore I include the following lines specific to CocoaPods:

Pods/
#Podfile.lock  # changed my mind on Podfile.lock

Then I make sure that we have a copy of the libraries in a safe location. Rather than (mis-)use a project's code repository to store dependencies (compiled or not) I think the best way to do this is to archive builds. If you use a CI server for your builds (such as Jenkins) you can permanently archive any builds that are important to you. If you do all your production builds in your local Xcode, make a habit of taking an archive of your project for any builds you need to keep. Something like: 1. Product --> Archive

1. Distribute... Submit to the iOS App Store / Save for Enterprise or Ad-hoc Deployment / what have you

2. Reveal your project folder in Finder

3. Right click and Compress "WhateverProject"

This provides an as-built image of the entire project, including the complete project and workspace settings used to build the app as well as binary distributions (such as Sparkle, proprietary SDKs such as TestFlight, etc.) whether or not they use CocoaPods.

Update: I've changed my mind on this and now do commit the Podfile.lock to source control. However, I still believe that the pods themselves are build artifacts and should be managed as such outside of source control, through another method such as your CI server or an archive process like I describe above.

Answer 4

Seems like a good way to structure this really would be to have the "Pods" directory as a git submodule / separate project, here's why.

• Having pods in your project repo, when working with several developers, can cause VERY LARGE diffs in pull requests where it's nearly impossible to see the actual work that was changed by people (think several hundreds to thousands of files changed for libraries, and only a few changed in the actual project).

• I see the issue of not committing anything to git, as the person owning the library could take it down at any time and you're essentially SOL, this also solves that.

Answer 5

Personally I do not check in the Pods directory & contents. I can't say I spent long ages considering the implications but my reasoning is something like:

The Podfile refers to a specific tag or or commit of each dependency so the Pods themselves can be generated from the podfile, ergo they are more like an intermediate build product than a source and, hence, don't need version control in my project.

Answer 6

I generally work on app’s of clients. In that case I add the Pods directory to the repo as well, to ensure that at any given time any developer could do a checkout and build and run.

If it were an app of our own, I would probably exclude the Pods directory until I won’t be working on it for a while.

Actually, I must conclude I might not be the best person to answer your question, versus views of pure users :) I’ll tweet about this question from https://twitter.com/CocoaPodsOrg.