不签入pod /版本控制的优点(按重要性的主观顺序):

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. 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. 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. 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). Easier to discern how much someone contributes (since their lines of code contributed won't include dependencies they didn't write) 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.

不检查pod的缺点/

切换分支或还原提交时必须运行pod install。 您不能仅仅通过克隆存储库来运行项目。您必须安装pod工具，然后运行pod install。 你必须有互联网连接才能运行pod install，而且pod的源代码必须可用。 如果依赖的所有者删除了他们的包，你就不能使用它(尽管你一开始就不应该使用已弃用的依赖——这只会迫使你更早地进行依赖卫生)。

总之，不包含Pods目录是防止更多不良做法的屏障。包含Pods目录可以使项目更容易运行。比起后者，我更喜欢前者。如果一开始就不存在犯某些错误的可能性，那么你就不需要向项目中的每个新人汇报“什么不能做”。我也喜欢有一个单独的版本控制Pods的想法，这减轻了缺点。

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

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

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

我必须说，我是将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版本历史。

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

我更喜欢与Podfile和Podfile一起提交Pods目录。锁定，以确保我的团队中的任何人都可以随时签出源代码，他们不必担心任何事情或做额外的事情来使其工作。

如果您在某个pod中修复了一个错误，或者根据需要修改了一些行为，但如果没有提交，这些更改将无法在其他机器上使用，那么这也会有所帮助。

忽略不必要的目录:

xcuserdata/

就个人而言，这取决于:

为什么pod应该是repo的一部分(在源代码控制下)并且不应该被忽略

The source is identical You can build it right away as is (even without the cocoapods) Even if a pod is deleted, we still have its copy (Yes, this can happen and it did. In an old project where you want just a small change you would need to implement a new library to be able to even build). pods.xcodeproj settings are part of the source control as well. This means e.g. if you have the project in swift 4, but some pods must be in swift 3.2 because they are not updated yet, these settings will be saved. Otherwise the one who cloned the repo would end up with errors. You can always delete pods from the project and run pod install, the opposite can not be done. Even the authors of the Cocoapods recommend it.

缺点:更大的存储库，令人困惑的差异(主要针对团队成员)，潜在的冲突更多。

.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的讨论。