나는 두 달 동안 iOS 개발을 해왔으며 의존성 관리를위한 유망한 CocoaPods 라이브러리에 대해 알게되었습니다 .

개인 프로젝트에서 시도해 보았습니다. 키 포드에 Podfile에 의존성을 추가하고 실행 pod install CocoaPodsTest.xcodeproj하고 voila 을 추가하면 훌륭하게 작동했습니다.

내가 궁금해하는 유일한 것은 : 무엇을 체크인하고, 버전 제어를 위해 무엇을 무시 하는가? Podfile 자체와 .xcworkspace 파일도 체크인하고 싶은 것이 분명합니다. 그러나 Pods / 디렉토리를 무시합니까? .gitignore에 추가 해야하는 다른 파일이 있습니까 (다른 종속성을 추가 할 때) 계속 생성됩니까?

개인적으로 Pods 디렉토리 및 내용을 체크인하지 않습니다. 나는 그 의미를 고려하면서 오랜 시간을 보냈다고 말할 수는 없지만 내 추론은 다음과 같습니다.

Podfile은 특정 태그 또는 각 종속성의 커밋을 나타내므로 Pod 자체에서 Pod 자체를 생성 할 수 있습니다. 즉, 소스보다 중간 빌드 제품과 유사하므로 프로젝트에서 버전 제어가 필요하지 않습니다.

포드 디렉토리를 커밋합니다. Pods 디렉토리가 빌드 아티팩트라는 데 동의하지 않습니다. 사실 나는 그것이 가장 확실하지 않다고 말하고 싶습니다. 응용 프로그램 소스의 일부입니다. 응용 프로그램 소스 없이는 빌드되지 않습니다!

CocoaPods를 빌드 도구가 아닌 개발자 도구로 생각하기가 더 쉽습니다. 프로젝트를 빌드하지 않고 단순히 종속성을 복제하고 설치합니다. CocoaPods를 설치하지 않아도 프로젝트를 간단하게 구축 할 수 있습니다.

CocoaPods를 빌드의 종속성으로 만들면 프로젝트를 빌드하는 데 필요한 모든 곳에서 사용할 수 있는지 확인해야합니다. 팀 관리자가 필요하면 CI 서버에 필요합니다. 일반적으로 항상 소스 저장소를 복제하고 추가 노력없이 빌드 할 수 있어야합니다.

분기를 자주 전환하면 Pods 디렉토리를 커밋하지 않으면 엄청난 두통이 발생합니다. 이제 분기를 전환 할 때마다 포드 설치를 실행하여 종속성이 올바른지 확인해야합니다. 의존성이 안정화되면 번거 로움이 덜할 수 있지만 프로젝트 초기에는 시간이 많이 걸립니다.

그래서 나는 무엇을 무시합니까? 아무것도. Podfile, 잠금 파일 및 Pods 디렉토리가 모두 커밋됩니다. 날 믿어 라, 그것은 많은 번거 로움을 덜어 줄 것이다. 단점은 무엇입니까? 약간 큰 레포? 세상의 끝이 아닙니다.

GitHub의 Objective-C gitignore 사용하는 것이 좋습니다 . 구체적으로 모범 사례는 다음과 같습니다.

• 은 Podfile 해야한다 항상 소스 제어에서합니다.
• 은 Podfile.lock 해야한다 항상 소스 제어에서합니다.
• CocoaPods에 의해 생성 된 작업 공간 은 소스 제어하에 유지 되어야 합니다.
• :path옵션으로 참조 된 모든 포드 는 소스 제어하에 보관 해야 합니다.
• ./Pods폴더가 있습니다 소스 제어에서 유지 될 수있다.

자세한 내용은 공식 안내서를 참조하십시오 .

출처 : 저는 @alloy와 같은 CocoaPods 핵심 팀의 일원입니다.

Pods 폴더는 빌드 아티팩트이지만 소스 제어하에 둘 것인지를 결정할 때 고려해야 할 이유가 있습니다.

• CocoaPods는 패키지 관리자가 아니므로 저자가 라이브러리의 원본을 제거 할 수 있습니다.
• Pods 폴더가 소스 제어에 포함 된 경우 체크 아웃으로 프로젝트를 실행하기 위해 CocoaPods를 설치할 필요가 없습니다.
• CocoaPods는 여전히 진행 중이며 항상 같은 결과를 가져 오지 않는 옵션이 있습니다 (예 : :head및 :git옵션은 현재에 저장된 커밋을 사용하지 않습니다 Podfile.lock).
• 중간 / 장시간 후에 프로젝트 작업을 다시 시작할 수있는 경우 실패 지점이 줄어 듭니다.

.gitignore 파일

실제로 답변 을 제공 하지 .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/

포드 디렉토리 무시하기 ( 이점 )

.gitignore : (이전 목록에 추가)

# Cocoapods
Pods/

Pods 디렉토리의 체크인 여부에 관계없이 Podfile 및 Podfile.lock은 항상 버전 제어를 유지해야합니다.

Pods체크인하지 않은 경우 Podfile각 Cocoapod에 대해 명시적인 버전 번호를 요청해야합니다. Cocoapods.org 토론이 여기에 있습니다 .

나는 일반적으로 응용 프로그램의 클라이언트에서 일합니다. 이 경우에는 Pods 디렉토리를 repo에 추가하여 언제든지 개발자가 체크 아웃하고 빌드하고 실행할 수 있도록 보장합니다.

그것이 우리 자신의 응용 프로그램 인 경우, 잠시 동안 작업하지 않을 때까지 Pods 디렉토리를 제외시킬 것입니다.

실제로, 나는 순수한 사용자의 견해와 비교하여 귀하의 질문에 대답하기에 가장 좋은 사람이 아닐 수도 있다고 결론을 내야합니다 :) https://twitter.com/CocoaPodsOrg 에서이 질문에 대해 트윗 할 것 입니다.

나는 모든 것을 확인합니다. ( Pods/및Podfile.lock .)

리포지토리를 복제하고 마지막으로 앱을 사용할 때와 같이 모든 것이 작동한다는 것을 알고 싶습니다.

차라리 다른 버전의 gem으로 인해 발생할 수있는 다른 결과 나 포드의 저장소 등에서 기록을 다시 작성하는 등의 위험을 감수하는 것보다는 벤더를 선호합니다.

이에 대한 답변은 Cocoapod 문서에 직접 제공됩니다. " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "을 참조하십시오 .

워크 플로는 프로젝트마다 다르므로 Pods 폴더 체크인 여부는 사용자에게 달려 있습니다. Pods 디렉토리를 소스 제어 상태로 유지하고 .gitignore에 추가하지 않는 것이 좋습니다. 그러나 궁극적 으로이 결정은 당신에게 달려 있습니다 :

Pods 디렉토리 확인의 이점

• 저장소를 복제 한 후에는 컴퓨터에 CocoaPod를 설치하지 않아도 프로젝트를 즉시 빌드하고 실행할 수 있습니다. 포드 설치를 실행할 필요가 없으며 인터넷 연결이 필요하지 않습니다.
• 포드 소스 (예 : GitHub)가 다운 되더라도 포드 아티팩트 (코드 / 라이브러리)는 항상 사용 가능합니다.
• 포드 아티팩트는 리포지토리 복제 후 원래 설치의 아티팩트와 동일해야합니다.

포드 디렉토리를 무시할 때의 이점

• 소스 제어 저장소는 더 작고 공간을 덜 차지합니다.

• 모든 포드에 대한 소스 (예 : GitHub)를 사용할 수있는 경우 CocoaPod는 일반적으로 동일한 설치를 재현 할 수 있습니다. (Podfile에서 커밋 SHA를 사용하지 않을 때 포드 설치를 실행해도 동일한 아티팩트를 가져오고 다시 생성한다는 보장은 없습니다. 이는 Podfile에서 zip 파일을 사용할 때 특히 그렇습니다.)

• 다른 포드 버전과 브랜치를 병합하는 등 소스 제어 작업을 수행 할 때 다루어야 할 충돌이 없습니다.

Pods 디렉토리의 체크인 여부에 관계없이 Podfile 및 Podfile.lock은 항상 버전 제어를 유지해야합니다.

다른 위치에 좋은 사본이 있다고 가정하고 라이브러리를 체크인하지 않는 개발자 캠프에 있습니다. 따라서 내 .gitignore에는 CocoaPods와 관련된 다음 줄이 포함되어 있습니다.

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

그런 다음 안전한 위치에 라이브러리 사본이 있는지 확인하십시오. 프로젝트 코드 저장소를 사용하여 종속성을 컴파일하는 대신 (컴파일 여부에 관계없이) 빌드를 아카이브하는 것이 가장 좋습니다. Jenkins와 같은 빌드에 CI 서버를 사용하는 경우 중요한 빌드를 영구적으로 보관할 수 있습니다. 로컬 Xcode에서 모든 프로덕션 빌드를 수행하는 경우 유지해야 할 빌드마다 프로젝트 아카이브를 작성하는 습관을들입니다. 1. 제품-> 아카이브

1. 배포 ... iOS 앱 스토어에 제출 / Enterprise 또는 Ad-hoc 배포 용 저장 / 무엇을 보유하고 있습니까?

2. Finder에서 프로젝트 폴더를 공개하십시오

3. 마우스 오른쪽 버튼을 클릭하고 "WhateverProject"압축

CocoaPods 사용 여부에 관계없이 앱을 빌드하는 데 사용되는 전체 프로젝트 및 작업 영역 설정과 Spark 배포, TestFlight와 같은 독점 SDK 등의 바이너리 배포판을 포함하여 전체 프로젝트의 빌드 이미지를 제공합니다.

업데이트 : 나는 이것에 대해 마음이 바뀌었고 이제 Podfile.lock소스 제어에 전념합니다 . 그러나 여전히 포드 자체는 빌드 아티팩트이며 CI 서버 또는 위에서 설명한 아카이브 프로세스와 같은 다른 방법을 통해 소스 제어 외부에서 관리해야합니다.

나는 투입 선호 Pods와 함께 디렉토리 Podfile와 Podfile.lock소스 언제든지 체크 아웃 할 수 있습니다 내 팀에 확실히 사람을 만들기 위해 그들은 무엇에 대해 걱정할 필요가 있거나 작동하도록 추가로 물건을하지 않습니다.

이는 포드 중 하나의 버그를 수정했거나 필요에 따라 일부 동작을 수정 한 시나리오에서도 도움이되지만 이러한 변경 사항은 커밋되지 않은 경우 다른 시스템에서 사용할 수 없습니다.

그리고 불필요한 디렉토리를 무시하려면 :

xcuserdata/

나는 포드를 저장소에 커밋하는 팬입니다. 이미 언급 된 링크를 따르면 iOS 용 Xcode 프로젝트를 열어서 포드를 허용하지만 원하는 경우 쉽게 제외 할 수있는 좋은 .gitignore 파일을 얻을 수 있습니다 : https://github.com/github/gitignore/ Blob / 마스터 /Objective-C.gitignore

저장소에 포드를 추가하는 것을 좋아하는 이유는 아무도 선택하지 않는 근본적인 이유 때문입니다. 프로젝트가 의존하는 라이브러리가 웹에서 갑자기 제거되면 어떻게됩니까?

• 호스트가 더 이상 GitHub 계정을 열어 두지 않기로 결정한 경우 라이브러리가 몇 년이 지난 경우 (예 : 5 년 이상) 프로젝트가 더 이상 소스에서 제공되지 않을 가능성이 높은 경우
• 또 다른 요점은 리포지토리의 URL이 변경되면 어떻게됩니까? GitHub 계정에서 포드를 제공하는 사람이 다른 핸들로 자신을 표현하기로 결정했다고 가정 해 봅시다. 포드 URL이 깨질 것입니다.
• 마지막으로 또 다른 포인트. 국가 간 비행 중에 많은 코딩을 수행하는 나와 같은 개발자라면 말하십시오. 나는 '마스터'지점을 빠르게 당기고 공항에 앉아있는 동안 그 지점에 포드를 설치하고 곧 8 시간 동안 비행을 시작했습니다. 3 시간 동안 비행기를 타서 다른 지점으로 전환해야한다는 것을 알게되었습니다. 'DOH'- '마스터'지점에서만 사용할 수있는 포드 정보가 없습니다.

NB ... 개발을위한 '마스터'브랜치는 단지 예일 뿐이며, 버전 제어 시스템의 '마스터'브랜치는 항상 깨끗하고 배포 가능 / 빌드 가능하게 유지되어야합니다.

이것들로부터, 코드 저장소의 스냅 샷이 저장소 크기에 엄격한 것보다 확실히 낫습니다. 이미 언급했듯이 podfile.lock 파일-버전 제어는 포드 버전에 대한 좋은 기록을 제공합니다.

하루가 끝날 때 마감 시간이 촉박하고 예산이 적고 시간이 핵심이라면 우리는 가능한 한 많은 자원이 필요하고 엄격한 이데올로기에 시간을 낭비하지 말고 함께 일할 도구 세트를 활용해야합니다. -삶을 더 효율적으로 만들기 위해.

결국 당신이 취하는 접근 방식은 당신에게 달려 있습니다.

이것이 Cocoapods 팀이 생각하는 것입니다.

워크 플로는 프로젝트마다 다르므로 Pods 폴더 체크인 여부는 사용자에게 달려 있습니다. Pods 디렉토리를 소스 제어 상태로 유지하고 .gitignore에 추가하지 않는 것이 좋습니다. 그러나 궁극적으로이 결정은 당신에게 달려 있습니다.

개인적으로 나는 계속하고 싶습니다 포드 로, 밖으로 node_modules 내가 사용한다면 노드 또는 bower_components을 내가 사용하고있는 경우 정자를 . 이것은 거의 모든 Dependency Manager에 적용되며 git 하위 모듈 의 철학입니다. 입니다.

그러나 때로는 특정 종속성의 최첨단 에 대해 정말로 확신하고 싶을 수도 있습니다. 이렇게 하면 프로젝트 내에서 종속성을 소유하게됩니다. 물론 그렇게 할 경우 적용되는 몇 가지 단점이 있지만, Cocoapod에만 적용되는 것이 아니라, Dependency Manager에 적용됩니다.

아래에는 좋은 장단점이 있습니다 Cocoapods 팀 목록과 앞에서 언급 한 인용문의 전체 내용입니다.

Cocoapods 팀 : Pods 디렉토리를 소스 제어로 확인해야합니까?

그것은 개인적으로 달려 있습니다 :

포드가 소스 제어 하에서 저장소의 일부 여야하고 무시해서는 안되는 이유

• 소스는 동일합니다
• 코코아 포가 없어도 그대로 만들 수 있습니다.
• 포드가 삭제 된 경우에도 여전히 사본 이 있습니다.
• pods.xcodeproj설정도 소스 컨트롤의 일부입니다. 예를 들어 프로젝트가 swift 4에 있지만 일부 포드가swift 3.2 아직 업데이트되지 않아 이러한 설정이 저장됩니다. 그렇지 않으면 레포를 복제 한 사람이 오류로 끝날 것입니다.
• 프로젝트에서 포드를 항상 삭제하고 실행할 pod install수 있으며 반대는 수행 할 수 없습니다.
• Cocoapod 의 저자 조차도 그것을 추천합니다.

일부 단점 : 더 큰 저장소, 혼란스러운 차이 (주로 팀 구성원의 경우), 잠재적으로 더 많은 충돌.

나에게 가장 큰 관심사는 앞으로 소스를 교정하는 것입니다. 프로젝트를 한동안 지속 시키려고하는데 CocoaPods가 사라지거나 포드 중 하나의 소스가 다운되면, 아카이브에서 새로 빌드하려고하면 완전히 운이 나빠집니다.

이는주기적인 전체 소스 보관으로 완화 할 수 있습니다.

포드를 체크인하십시오.

나는 이것이 소프트웨어 개발의 교리라고 생각한다

• 모든 빌드는 재현 가능해야합니다
• 빌드를 재현 할 수있는 유일한 방법은 모든 종속성을 제어하는 ​​것입니다. 따라서 모든 종속성을 체크인해야합니다.
• 처음부터 새로 시작한 개발자는 프로젝트를 확인하고 작업을 시작할 수 있습니다.

왜?

CocoaPods 또는 기타 외부 라이브러리가 변경되어 문제가 발생할 수 있습니다. 또는 이동하거나 이름이 변경되거나 완전히 제거 될 수 있습니다. 인터넷을 통해 물건을 보관할 수는 없습니다. 랩톱이 죽었을 수 있으며 수정해야 할 중요한 버그가 있습니다. 주요 개발자가 버스에 맞을 수 있으며 그의 교체품은 서둘러 시작해야합니다. 그리고 마지막 예제가 이론적 인 예 였으면 좋았지 만 실제로는 제가 시작했을 때 일어났습니다. 삼가 고인의 명복을 빕니다.

이제 현실적으로 모든 종속성을 확인할 수는 없습니다. 빌드를 작성하는 데 사용한 머신 이미지를 체크인 할 수 없습니다. 정확한 버전의 컴파일러를 체크인 할 수 없습니다. 등등. 현실적인 한계가 있습니다. 그러나 할 수있는 모든 것을 확인하십시오. 그렇게하지 않으면 인생이 더 어려워집니다. 그리고 우리는 그것을 원하지 않습니다.

마지막 단어 : 포드는 아티팩트가 아닙니다. 빌드 아티팩트는 빌드에서 생성되는 것입니다. 빌드는 포드를 생성하지 않고 포드를 사용합니다. 왜 이것이 논쟁되어야하는지 잘 모르겠습니다.

버전 관리에 체크인 하지 않는 장점 Pods/(주관적인 순서로) :

1. 커밋을 병합하고 코드 차이를 검토하는 것이 훨씬 쉽습니다. 병합은 코드 기반의 일반적인 문제 소스이며이를 통해 관련있는 항목에만 집중할 수 있습니다.
2. 일부 무작위 기여자가 의존성을 직접 편집하고 변경 사항을 확인하는 것은 불가능합니다. 변경 사항은 절대로 피해야합니다 (그리고 diff가 대규모인지 확인하기가 어렵습니다). 의존성을 편집하는 것은 미래 pod install가 변경을 막을 수 있기 때문에 매우 좋지 않습니다 .
3. 팀원들 사이 Podfile에서 Pods/디렉토리 와 디렉토리 간의 불일치가 더 빨리 발견됩니다. Pods/예를 들어에서 버전 을 체크인하고 업데이트 Podfile했지만 pod install변경 사항을 실행 하거나 체크인하는 것을 잊어 버린 Pods/경우 불일치의 원인을 파악하기가 훨씬 더 어려워집니다. Pods/체크인되지 않은 경우 항상 실행해야 pod install합니다.
4. 더 작은 저장소 크기. 더 작은 바이트-풋 프린트를 갖는 것은 좋지만, 그랜드 스킴에서는 그다지 중요하지 않습니다. 더 중요한 것은 : repo에 더 많은 것들이 있으면인지 부하가 ​​증가한다는 것입니다. 리포지토리에 보지 말아야 할 것을 가질 이유가 없습니다. 코드 (구현)가 아닌 무언가가 어떻게 작동하는지 알기 위해 문서 (추상화)를 참조하십시오.
5. 누군가가 얼마나 많은 기여를하는지 쉽게 식별 할 수 있습니다.
6. JAR파일 .venv/(가상 환경)이며 node_modules/버전 관리에 포함되지 않습니다. 우리가 질문에 대해 완전히 무관심하다면, 체크인 하지 않는Pods 것이 선례에 따른 기본값이 될 것입니다.

체크인 하지 않는 단점Pods/

1. 당신은 실행해야합니다 pod install분기를 전환하거나 커밋을 되돌릴 때 .
2. 리포지토리를 복제하는 것만으로 프로젝트를 실행할 수 없습니다. 포드 도구를 설치 한 다음을 실행해야합니다 pod install.
3. 을 (를) 실행하려면 인터넷에 연결되어 pod install있어야하며 포드의 소스를 사용할 수 있어야합니다.
4. 종속성 소유자가 패키지를 제거하면 문제가있는 것입니다.

요약하면, 포함하지Pods 디렉토리하는 것은 더 나쁜 관행에 대한 가드 레일입니다. 디렉토리를 포함 하면 Pods프로젝트를보다 쉽게 ​​실행할 수 있습니다. 나는 후자를 선호한다. 처음에 특정 실수를 할 가능성이 없다면 "하지 말아야 할 일" 에 대해 프로젝트에 참여한 모든 새로운 사람을보고 할 필요 는 없습니다. 또한 Pods단점을 완화시키는 별도의 버전 관리 기능이 있다는 아이디어가 마음 에 듭니다.

이론적으로 Pods 디렉토리를 체크인해야합니다. 실제로 항상 작동하지는 않습니다. 많은 포드는 github 파일의 크기 제한을 초과하므로 github을 사용하는 경우 Pods 디렉토리에서 확인하는 데 문제가 있습니다.

TL; DR : Pods/폴더 를 추적 하면 프로젝트를 더 쉽게 찾을 수 있습니다. 추적하지 않으면 팀에서 일할 때 개선하기가 더 쉽습니다.

Cocoapods 조직은 Pods/디렉토리 를 추적하도록 권장하지만 다음과 같은 장단점에 따라 디렉토리를 수행할지 여부를 결정하는 것은 개발자의 몫이라고 말합니다.  http://guides.cocoapods.org/using/using-cocoapods.html # should-i-check-the-pods 디렉토리에서 소스로 제어

개인적으로, 나는 Pods/더 이상 한동안 더 이상 작업하지 않을 프로젝트에 대해서만 폴더를 추적합니다 . 그렇게하면 모든 개발자가 적절한 버전의 코코아 포드를 사용하여 작업을 계속 진행할 수 있습니다.

반면에 커밋 기록은 더 깨끗 해지고 Pods/폴더를 추적하지 않을 때 코드를 병합하고 다른 사람의 코드를 쉽게 검토 할 수 있다고 생각 합니다. 나는 보통 cocoapod 라이브러리의 버전을 설치할 때 누군가와 같은 버전을 사용하여 프로젝트를 설치할 수 있도록 설치한다.

또한 Pods/디렉토리를 추적 할 때 모든 개발자는 pod install포드를 추가 / 제거하기 위해 실행할 때마다 수십 개의 파일이 변경되지 않도록 동일한 버전의 Cocoapod를 사용해야합니다 .

결론 : Pods/폴더 를 추적 하면 프로젝트를 더 쉽게 찾을 수 있습니다. 추적하지 않으면 개선하기가 더 쉽습니다.

이것을 구성하는 좋은 방법 인 것처럼 실제로 "Pods"디렉토리를 git 서브 모듈 / 별도 프로젝트로 사용하는 것 같습니다. 여기에 이유가 있습니다.

• 여러 개발자와 함께 작업 할 때 프로젝트 저장소에 포드를 사용하면 사람들이 변경 한 실제 작업을 거의 볼 수없는 풀 요청에서 매우 큰 차이가 발생할 수 있습니다. 실제 프로젝트에서 거의 변경되지 않았습니다.

• 라이브러리를 소유 한 사람이 언제든지 라이브러리를 중단 할 수 있고 본질적으로 SOL이기 때문에 git에 커밋하지 않는 문제가 있습니다.이 또한 해결합니다.

워크 플로는 프로젝트마다 다르므로 Pods 폴더 체크인 여부는 사용자에게 달려 있습니다. Pods 디렉토리를 소스 제어 상태로 유지하고 .gitignore에 추가하지 않는 것이 좋습니다. 그러나 궁극적 으로이 결정은 당신에게 달려 있습니다 :

Pods 디렉토리 확인의 이점

1. 저장소를 복제 한 후에는 컴퓨터에 CocoaPod를 설치하지 않아도 프로젝트를 즉시 빌드하고 실행할 수 있습니다. 포드 설치를 실행할 필요가 없으며 인터넷 연결이 필요하지 않습니다.
2. 포드 소스 (예 : GitHub)가 다운 되더라도 포드 아티팩트 (코드 / 라이브러리)는 항상 사용 가능합니다.
3. 포드 아티팩트는 리포지토리 복제 후 원래 설치의 아티팩트와 동일해야합니다.

포드 디렉토리를 무시할 때의 이점

1. 소스 제어 저장소는 더 작고 공간을 덜 차지합니다. 모든 포드에 대한 소스 (예 : GitHub)를 사용할 수있는 경우 CocoaPods는 일반적으로 동일한 설치를 다시 생성 할 수 있습니다 (기술적으로 Pod 파일에서 커밋 SHA를 사용하지 않을 때 포드 설치를 실행해도 동일한 아티팩트를 가져오고 다시 생성한다는 보장은 없습니다. Podfile에서 zip 파일을 사용할 때 특히 그렇습니다.)
2. 다른 포드 버전과 브랜치를 병합하는 등 소스 제어 작업을 수행 할 때 다루어야 할 충돌이 없습니다. Pods 디렉토리의 체크인 여부에 관계없이 Podfile 및 Podfile.lock은 항상 버전 제어를 유지해야합니다.