如果你正在使用CocoaPods，你的.gitignore会有什么？

本文翻译自：What goes into your .gitignore if you're using CocoaPods?

I've been doing iOS development for a couple of months now and just learned of the promising CocoaPods library for dependency management. 我已经进行了几个月的iOS开发，并且刚刚学习了有用的依赖管理CocoaPods库。

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. 我在个人项目上试了一下：在我的Podfile中添加了对Kiwi的依赖，运行了pod install CocoaPodsTest.xcodeproj ， 瞧 ，它运行得很好。

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; 很明显，我想检查Podfile本身，也可能是.xcworkspace文件; but do I ignore the Pods/ directory? 但是我会忽略Pods /目录吗？ Are there other files that will be generated down the road (when I add other dependencies) that I should also add to my .gitignore? 是否还有其他文件将在未来生成（当我添加其他依赖项时），我还应该添加到我的.gitignore中？

---

#1楼

参考：https://stackoom.com/question/ddVE/如果你正在使用CocoaPods-你的-gitignore会有什么

---

#2楼

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: 所以，在我的.gitignore中，我包含了以下特定于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. 如果为构建使用CI服务器（例如Jenkins），则可以永久存档对您很重要的任何构建。 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. 如果您在本地Xcode中执行所有生产版本，那么习惯于为您需要保留的任何版本存档项目。 Something like: 1. Product --> Archive 类似的东西：1。产品 - >存档

1. Distribute... Submit to the iOS App Store / Save for Enterprise or Ad-hoc Deployment / what have you 分发...提交到iOS App Store / Save for Enterprise或Ad-hoc Deployment /你有什么

2. Reveal your project folder in Finder 在Finder中显示项目文件夹

3. Right click and Compress "WhateverProject" 右键单击并压缩“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. 这提供了整个项目的竣工图像，包括用于构建应用程序的完整项目和工作区设置以及二进制发行版（如Sparkle，专有SDK，如TestFlight等），无论它们是否使用CocoaPods。

Update: I've changed my mind on this and now do commit the Podfile.lock to source control. 更新：我已经改变了主意，现在确实将Podfile.lock提交给源代码控制。 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. 但是，我仍然认为pod本身是构建工件，应该通过其他方法（如CI服务器或上面描述的存档过程）在源代码控制之外进行管理。

---

#3楼

I check in everything. 我检查一切。 ( Pods/ and Podfile.lock .) （ Pods/和Podfile.lock 。）

I want to be able to clone the repository and know that everything will just work as it did last time I used the app. 我希望能够克隆存储库并知道一切都会像上次使用应用程序一样工作。

I'd rather vendor things in than risk having different results that could be caused by a different version of the gem, or someone rewriting history in the Pod's repository, etc. 我宁愿供应商品而不是风险，因为不同版本的宝石可能导致不同的结果，或者有人在Pod的存储库中重写历史记录等。

---

#4楼

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. 我更喜欢将Pods目录与Podfile和Podfile.lock一起Podfile ，以确保我的团队中的任何人都可以随时检查源代码，他们不必担心任何事情或做其他事情来使其工作。

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. 这也有助于您修复其中一个pod中的错误或根据您的需要修改某些行为，但如果未提交，这些更改将无法在其他计算机上使用。

And to ignore unnecessary directories: 并忽略不必要的目录：

xcuserdata/

---

#5楼

I recommend to use the GitHub's Objective-C gitignore . 我建议使用GitHub的Objective-C gitignore 。 In detail, the best practices are: 详细而言，最佳做法是：

• The Podfile must always be under source control. Podfile 必须始终受源代码管理。
• The Podfile.lock must always be under source control. Podfile.lock 必须始终在源代码管理下。
• The Workspace generated by CocoaPods should be kept under source control. CocoaPods生成的工作空间应保持在源代码管理之下。
• Any Pod referenced with the :path option should be kept under source control. 使用:path选项引用的任何Pod 应保持在源代码管理下。
• The ./Pods folder can be kept under source control. ./Pods文件夹可以保持在源代码管理下。

For more information you can refer to the official guide . 有关更多信息，请参阅官方指南 。

source: I'm a member of the CocoaPods core team, like @alloy 来源：我是CocoaPods核心团队的成员，比如@alloy

---

Although the Pods folder is a build artifact there are reasons that you might consider while deciding wether to keep it under source control: 虽然Pods文件夹是一个构建工件，但是在决定使用它时可能会考虑将其保持在源代码控制之下：

• CocoaPods is not a package manager so the original source of the library could be removed in future by the author. CocoaPods不是包管理器，因此作者将来可以删除库的原始源。
• If the Pods folder is included in source control, it is not necessary to install CocoaPods to run the project as the checkout would suffice. 如果Pods文件夹包含在源代码管理中，则无需安装CocoaPods来运行项目，因为结帐就足够了。
• CocoaPods is still work in progress and there are options which don't always lead to the same result (for example the :head and the :git options currently are not using the commits stored in the Podfile.lock ). CocoaPods仍在进行中，并且有些选项并不总是导致相同的结果（例如:head和:git选项当前没有使用存储在Podfile.lock中的Podfile.lock ）。
• There are less points of failure if you might resume work on a project after a medium/long amount of time. 如果您可以在中/长时间后恢复项目工作，则可以减少故障点。

---

#6楼

I commit my Pods directory. 我提交了我的Pods目录。 I don't agree that the Pods directory is a build artefact. 我不同意Pods目录是一个构建工件。 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. 将CocoaPods视为开发人员工具而不是构建工具更容易。 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. 没有必要安装CocoaPods才能简单地构建您的项目。

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. 通过使CocoaPods成为构建的依赖项，您现在需要确保它可用于构建项目所需的任何位置......团队管理员需要它，您的CI服务器需要它。 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. 如果您经常切换分支，则不提交您的Pod目录也会造成巨大的麻烦。 Now you need to run pod install every time you switch branches to make sure your dependencies are correct. 现在，每次切换分支时都需要运行pod安装，以确保依赖关系正确。 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. Podfile，锁定文件和Pods目录都已提交。 Trust me, it will save you a lot of hassle. 相信我，它会为你节省很多麻烦。 What are the cons? 有什么缺点？ A slightly bigger repo? 一个稍大的回购？ Not the end of the world. 不是世界末日。