我已经做了几个月的iOS开发了，刚刚了解到有前途的用于依赖管理的CocoaPods库。
我在一个个人项目中尝试过:在我的Podfile中添加了对Kiwi的依赖，运行pod install CocoaPodsTest。Xcodeproj，瞧，它工作得很好。
我唯一想知道的是:我要签入什么，为了版本控制我要忽略什么?似乎很明显，我想签入Podfile本身，也可能是.xcworkspace文件;但是我是否忽略了Pods/目录?是否还会生成其他文件(当我添加其他依赖项时)，也应该添加到.gitignore中?
当前回答
将“Pods”目录作为一个git子模块/单独的项目似乎是一种很好的结构方式，原因如下。
在项目回购中使用pod，当与多个开发人员一起工作时，可能会在pull请求中造成非常大的差异，几乎不可能看到人们更改的实际工作(想象一下库更改了数百到数千个文件，而实际项目中只更改了少数文件)。 我看到了不向git提交任何东西的问题，因为拥有库的人可以随时删除它，而你实际上是SOL，这也解决了这个问题。
其他回答
理论上，您应该在Pods目录中进行检查。在实践中，这并不总是有效的。许多pod都超过了github文件的大小限制，所以如果你使用github，你将会在检查pods目录时遇到问题。
是否检入Pods文件夹取决于您，因为工作流程因项目而异。我们建议您将Pods目录置于源代码控制之下，不要将其添加到.gitignore中。但最终这个决定取决于你:
签入Pods目录的好处
克隆repo之后，项目可以立即构建和运行，甚至不需要在机器上安装CocoaPods。不需要运行pod install，也不需要连接互联网。 Pod构件(代码/库)总是可用的，即使Pod的源(例如GitHub)宕机。 克隆repo后，Pod工件保证与原始安装中的工件相同。
忽略Pods目录的好处
The source control repo will be smaller and take up less space. As long as the sources (e.g. GitHub) for all Pods are available, CocoaPods is generally able to recreate the same installation.(Technically there is no guarantee that running pod install will fetch and recreate identical artifacts when not using a commit SHA in the Podfile. This is especially true when using zip files in the Podfile.) There won't be any conflicts to deal with when performing source control operations, such as merging branches with different Pod versions. Whether or not you check in the Pods directory, the Podfile and Podfile.lock should always be kept under version control.
我更喜欢与Podfile和Podfile一起提交Pods目录。锁定，以确保我的团队中的任何人都可以随时签出源代码，他们不必担心任何事情或做额外的事情来使其工作。
如果您在某个pod中修复了一个错误，或者根据需要修改了一些行为，但如果没有提交，这些更改将无法在其他机器上使用，那么这也会有所帮助。
忽略不必要的目录:
xcuserdata/
每件事我都要登记。(Pods/和Podfile.lock。)
我希望能够克隆存储库，并知道一切将只是工作，因为它上次我使用的应用程序。
我宁愿把东西卖进来，也不愿意冒险，因为不同版本的宝石可能会导致不同的结果，或者有人重写Pod的存储库中的历史等等。
将“Pods”目录作为一个git子模块/单独的项目似乎是一种很好的结构方式，原因如下。
在项目回购中使用pod，当与多个开发人员一起工作时，可能会在pull请求中造成非常大的差异，几乎不可能看到人们更改的实际工作(想象一下库更改了数百到数千个文件，而实际项目中只更改了少数文件)。 我看到了不向git提交任何东西的问题，因为拥有库的人可以随时删除它，而你实际上是SOL，这也解决了这个问题。
