.gitignore file

没有答案真的提供了。gitignore，所以这里有两种口味。

在Pods目录中检查(好处)

Xcode/iOS友好的git忽略，跳过Mac OS系统文件，Xcode，构建，其他存储库和备份。

. gitignore:

# Mac OS X Finder
.DS_Store

# Private Keys
*.pem

# Xcode legacy
*.mode1
*.mode1v3
*.mode2v3
*.perspective
*.perspectivev3
*.pbxuser

# Xcode
xcuserdata/
project.xcworkspace/
DerivedData/

# build products
build/
*.[oa]

# repositories
.hg
.svn
CVS

# automatic backup files
*~.nib
*.swp
*~
*(Autosaved).rtfd/
Backup[ ]of[ ]*.pages/
Backup[ ]of[ ]*.key/
Backup[ ]of[ ]*.numbers/

忽略Pods目录(好处)

.gitignore:(附加到前面的列表)

# Cocoapods
Pods/

不管你是否检查Pods目录，Podfile和Podfile。Lock应该始终保持在版本控制之下。

如果pod没有签入，您的Podfile可能需要为每个Cocoapod请求明确的版本号。Cocoapods.org的讨论。

我必须说，我是将pod提交到存储库的粉丝。按照前面提到的链接，你会得到一个很好的。gitignore文件来启动你的iOS Xcode项目，以允许Pods，但如果你愿意，你也可以轻松地排除它们:https://github.com/github/gitignore/blob/master/Objective-C.gitignore

我之所以热衷于将pod添加到存储库中，有一个根本原因，但似乎没有人注意到，如果我们的项目如此依赖的库突然从网络上删除了，会发生什么?

Maybe the host decides they no longer want to keep their GitHub account open What happens if the library is say several years old (like older than 5 years for example) there is a high risk the project may no longer be available at source Also another point, what happens if the URL to the repository changes? Lets say the person serving the Pod from their GitHub account, decides to represent themselves under a different handle - your Pods URLs are going to break. Finally another point. Say if you're a developer like me who does a lot of coding when on a flight between countries. I do a quick pull on the 'master' branch, do a pod install on that branch, while sitting in the airport and have myself all set for the upcoming 8 hour flight. I get 3 hours into my flight, and realise I need to switch to another branch.... 'DOH' - missing Pod information which is only available on the 'master' branch.

NB……请注意，用于开发的“主”分支只是举个例子，很明显，版本控制系统中的“主”分支应该保持干净，并且在任何时候都可以部署/构建

我认为从这些方面来看，在代码存储库中创建快照肯定比严格限制存储库大小要好。如前所述，播客文件。锁文件-而版本控制将给你一个良好的Pod版本历史。

在一天结束的时候，如果你有一个紧迫的截止日期，预算紧张，时间是至关重要的——我们需要尽可能多的资源，不要把时间浪费在严格的意识形态上，而是利用一套工具一起工作——让我们的生活更容易、更有效。

每件事我都要登记。(Pods/和Podfile.lock。)

我希望能够克隆存储库，并知道一切将只是工作，因为它上次我使用的应用程序。

我宁愿把东西卖进来，也不愿意冒险，因为不同版本的宝石可能会导致不同的结果，或者有人重写Pod的存储库中的历史等等。

是否检入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.

我属于不签入库的开发人员阵营，假设我们在其他位置有一个好的副本可用。因此，在我的.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. 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

分配……提交到iOS应用商店/保存为企业或Ad-hoc部署/等等 在Finder中显示您的项目文件夹 右键压缩WhateverProject

这提供了整个项目的构建映像，包括用于构建应用程序的完整项目和工作区设置，以及二进制发行版(如Sparkle，专有sdk，如TestFlight等)，无论他们是否使用CocoaPods。

更新:我已经改变了我的想法，现在提交Podfile。锁定源代码控制。然而，我仍然相信pod本身是构建工件，应该在源代码控制之外进行管理，通过另一种方法，如CI服务器或如上所述的存档过程。

我建议使用GitHub的Objective-C gitignore。 具体来说，最佳实践是:

Podfile必须始终处于源代码控制之下。 Podfile。Lock必须始终处于源代码控制之下。 CocoaPods生成的工作区应该保持在源代码控制之下。 任何使用:path选项引用的Pod都应该保存在源代码控制下。 ./Pods文件夹可以保存在源代码控制下。

要了解更多信息，您可以参考官方指南。

来源:我是CocoaPods核心团队的成员，就像@alloy一样

尽管Pods文件夹是一个构建工件，但在决定是否将其置于源代码控制之下时，您可能会考虑以下原因:

CocoaPods is not a package manager so the original source of the library could be removed in future by the author. 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. 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). There are less points of failure if you might resume work on a project after a medium/long amount of time.