코코아 포드를 사용할 경우 .gitnore에 어떤 변화가 있습니까?

코코아 포드를 사용할 경우 .gitnore에 어떤 변화가 있습니까?

저는 iOS 개발을 몇 달 동안 해왔고 이제 막 의존성 관리를 위한 유망한 코코아 포드 라이브러리에 대해 알게 되었습니다.

저는 개인 프로젝트에서 그것을 시도했습니다: 제 팟 파일에 키위에 대한 종속성을 추가하고 실행했습니다.pod install CocoaPodsTest.xcodeproj그리고 voila, 그것은 잘 작동했습니다.

궁금한 것은 체크인하는 항목과 버전 제어를 위해 무시하는 항목입니다.Pod 파일 자체와 아마도 .xcworkspace 파일도 체크인하고 싶은 것이 분명합니다. 하지만 Pods/ 디렉토리는 무시합니까?앞으로 (다른 종속성을 추가할 때) 생성될 다른 파일이 있습니까? gitignore에 추가해야 합니까?

포드 디렉터리를 커밋합니다.포드 디렉터리가 빌드 아티팩트라는 것에 동의하지 않습니다.사실 저는 그것이 절대 아니라고 말하고 싶습니다.애플리케이션 소스의 일부입니다. 없이는 구축할 수 없습니다!

코코아 포드를 빌드 도구가 아닌 개발자 도구로 생각하는 것이 더 쉽습니다.프로젝트를 구축하는 것이 아니라 종속성을 복제하고 설치하는 것입니다.단순히 프로젝트를 구축하기 위해 코코아 포드를 설치할 필요는 없습니다.

CocoaPods를 빌드에 종속되도록 함으로써 이제 프로젝트를 빌드하는 데 필요한 모든 곳에서 사용할 수 있도록 해야 합니다. 팀 관리자가 필요로 하고 CI 서버가 필요로 합니다.기본적으로 소스 저장소를 복제하고 추가 작업 없이 구축할 수 있어야 합니다.

또한 분기를 자주 전환하는 경우 Pods 디렉토리를 커밋하지 않으면 큰 문제가 발생합니다.이제 분기를 전환할 때마다 포드 설치를 실행하여 종속성이 올바른지 확인해야 합니다.이는 의존성이 안정화됨에 따라 덜 번거로울 수 있지만 프로젝트 초기에는 시간이 많이 소요됩니다.

그럼, 내가 무시하는 것은 무엇일까요?아무 것도 없어요.포드 파일, 잠금 파일 및 포드 디렉터리가 모두 커밋됩니다.저를 믿으세요, 그러면 당신의 번거로움을 많이 줄일 수 있을 거예요.단점은 무엇입니까?조금 더 큰 레포?세상의 끝이 아닙니다.

개인적으로 저는 포드 디렉터리와 콘텐츠를 체크인하지 않습니다.시사점을 고려하면서 오랜 시간을 보냈다고 말할 수는 없지만, 제 추론은 다음과 같습니다.

포드 파일은 각 종속성의 특정 태그 또는 커밋을 참조하므로 포드 자체가 포드 파일에서 생성될 수 있습니다. 따라서 소스라기보다는 중간 빌드 제품에 가깝기 때문에 제 프로젝트에서 버전 제어가 필요하지 않습니다.

GitHub의 Objective-C를 무시하는 것을 추천합니다.세부적으로 모범 사례는 다음과 같습니다.

• 그Podfile 항상 소스 제어 하에 있어야 합니다.
• 그Podfile.lock 항상 소스 제어 하에 있어야 합니다.
• 코코아 포드에서 생성된 작업 공간은 소스 제어 하에 유지되어야 합니다.
• 참조된 :path옵션은 소스 제어 하에 유지되어야 합니다.
• 그./Pods폴더는 소스 제어 하에 유지할 수 있습니다.

자세한 내용은 공식 가이드를 참조할 수 있습니다.

출처: 저는 @alloy와 같은 코코아 포드 점수 팀의 일원입니다.

---

Pods 폴더는 빌드 아티팩트이지만 소스 제어 상태로 유지할지 여부를 결정할 때 고려할 수 있는 이유는 다음과 같습니다.

• 코코아 포드는 패키지 관리자가 아니므로 나중에 작성자가 라이브러리의 원래 소스를 제거할 수 있습니다.
• Pods 폴더가 소스 제어에 포함되어 있으면 프로젝트를 실행하기 위해 코코아 포드를 설치할 필요가 없습니다. 체크아웃만 하면 됩니다.
• 결과를 예: " 코아포드여는예작전중업항이결이동있않다습옵니지는션이어지과로상일코한며히예▁cocoa▁which(있습니다옵for:션이s않pod▁(는▁options▁are지이▁there지어코▁result▁don▁in▁is▁the▁example▁still코▁same▁and▁the▁to").: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/

---

Pods 디렉토리 무시(장점)

.gitignore: (이전 목록과 비교)

# Cocoapods
Pods/

Pods 디렉토리를 체크인하든 하지 않든, Podfile과 Podfile.lock은 항상 버전 제어 하에 있어야 합니다.

한다면PodsPodfile각 Cocoapod에 대해 명시적인 버전 번호를 요청해야 합니다.Cocoapods.org 여기서 토론합니다.

저는 일반적으로 고객들의 앱에서 일합니다.이 경우, 저는 어떤 개발자라도 언제든지 체크아웃하고 빌드하고 실행할 수 있도록 포드 디렉터리도 레포에 추가합니다.

만약 그것이 우리만의 앱이었다면, 나는 아마도 당분간 그것을 작업하지 않을 때까지 포드 디렉터리를 제외했을 것입니다.

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

저는 모든 것을 확인합니다.(Pods/그리고.Podfile.lock.)

저장소를 복제할 수 있고 지난 번 앱을 사용했을 때처럼 모든 것이 작동한다는 것을 알고 싶습니다.

저는 다른 버전의 보석이나 누군가가 포드의 저장소에 기록을 다시 쓰는 등으로 인해 발생할 수 있는 다른 결과를 초래할 위험을 감수하는 것보다 물건을 공급하는 것을 선호합니다.

이에 대한 답은 Cocoapod 문서에 직접 나와 있습니다.당신은 "http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "을 볼 수 있습니다.

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

Pods 디렉토리에서 확인할 경우의 이점

• 레포를 복제한 후, 이 프로젝트는 기계에 코코아 포드를 설치하지 않아도 즉시 빌드하고 실행할 수 있습니다.포드 설치를 실행할 필요가 없으며 인터넷 연결도 필요하지 않습니다.
• Pod의 소스(예: GitHub)가 중단되더라도 Pod 아티팩트(코드/라이브러리)는 항상 사용할 수 있습니다.
• Repo 복제 후 Pod 아티팩트는 원래 설치의 아티팩트와 동일하게 유지됩니다.

포드 디렉터리를 무시할 경우의 이점

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

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

• 서로 다른 Pod 버전의 분기를 병합하는 등 소스 제어 작업을 수행할 때 처리해야 할 충돌이 없습니다.

Pods 디렉토리를 체크인하든 하지 않든, Podfile과 Podfile.lock은 항상 버전 제어 하에 있어야 합니다.

저는 도서관을 방문하지 않는 개발자들의 캠프에 있습니다. 다른 곳에서 사용할 수 있는 좋은 복사본이 있다고 가정하면 말이죠.따라서 .gitignore에 다음과 같은 코코아 포드 관련 라인을 포함합니다.

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

그러면 도서관의 복사본을 안전한 장소에 보관하도록 하겠습니다.프로젝트의 코드 저장소를 사용하여 종속성(컴파일 여부와 상관없이)을 저장하는 것보다 빌드를 아카이브하는 것이 가장 좋은 방법이라고 생각합니다.빌드에 CI 서버(예: Jenkins)를 사용하는 경우 중요한 빌드를 영구적으로 아카이브할 수 있습니다.모든 프로덕션 빌드를 로컬 Xcode로 수행하는 경우 보관해야 하는 빌드에 대해 프로젝트를 보관하는 습관을 들입니다.다음과 같은 것: 1. 제품 --> 보관

1. 배포...iOS App Store에 제출 / 엔터프라이즈 또는 애드혹 배포를 위해 저장 / 어떤 기능이 있습니까?

2. 파인더에서 프로젝트 폴더 표시

3. 마우스 오른쪽 버튼을 클릭하고 "모든 프로젝트"를 압축합니다.

이렇게 하면 응용프로그램을 구축하는 데 사용되는 전체 프로젝트 및 작업 공간 설정뿐만 아니라 코코아 포드 사용 여부에 관계없이 이진 배포(예: Sparkle, TestFlight 등의 독점 SDK)를 포함한 전체 프로젝트의 애즈-빌트 이미지를 제공합니다.

업데이트: 나는 이것에 대한 생각을 바꿨고 지금은 커밋합니다.Podfile.lock소스 제어로 이동합니다.하지만 포드 자체는 빌드 아티팩트이므로 CI 서버나 위에서 설명한 아카이브 프로세스와 같은 다른 방법을 통해 소스 제어 외부에서 관리해야 한다고 생각합니다.

나는 커밋하는 것을 선호합니다.Pods와 디토와께함렉리▁alongPodfile그리고.Podfile.lock우리 팀의 모든 사람이 언제든지 소스를 확인할 수 있고, 그들은 그것을 작동시키기 위해 아무것도 걱정하거나 추가적인 일을 할 필요가 없습니다.

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

불필요한 디렉토리를 무시하는 방법:

xcuserdata/

저는 팟들을 저장소에 헌신하는 팬이라고 말해야겠습니다.이미 언급된 링크를 따라가면 iOS용 Xcode 프로젝트를 시작할 수 있는 좋은 .gitignore 파일이 제공됩니다. https://github.com/github/gitignore/blob/master/Objective-C.gitignore .

제가 팟을 저장소에 추가하는 것을 좋아하는 이유는 아무도 알아채지 못하는 것처럼 보이는 한 가지 근본적인 이유 때문입니다. 우리 프로젝트에 의존하는 라이브러리가 갑자기 웹에서 제거되면 어떻게 될까요?

• 호스트가 GitHub 계정을 더 이상 열지 않기로 결정할 수 있습니다. 라이브러리가 몇 년(예: 5년 이상 된 경우)이라고 하면 프로젝트를 더 이상 소스에서 사용할 수 없을 위험이 높습니다.
• 또한 저장소에 대한 URL이 변경되면 어떻게 됩니까?GitHub 계정에서 포드를 서비스하는 사람이 다른 핸들로 자신을 표현하기로 결정했다고 가정해 보겠습니다. 포드 URL이 손상될 것입니다.
• 마지막으로 또 다른 점입니다.저처럼 국가 간 비행기를 탈 때 코딩을 많이 하는 개발자라고 해보세요.저는 '마스터' 지점을 빠르게 잡아당기고, 공항에 앉아 8시간 동안 비행 준비를 합니다.비행기에 탑승한 지 3시간이 지났는데 다른 지점으로 전환해야 한다는 것을 깨달았습니다. 'DOH' - '마스터' 지점에서만 사용할 수 있는 포드 정보가 누락되었습니다.

NB... 개발을 위한 '마스터' 분기는 예를 들어 버전 제어 시스템의 '마스터' 분기는 언제든지 청결하게 유지되고 전개/구축 가능해야 합니다.

이를 통해 코드 저장소의 스냅샷이 저장소 크기를 엄격하게 지정하는 것보다 확실히 더 낫다고 생각합니다.그리고 이미 언급했듯이, podfile.lock 파일은 버전이 제어되는 동안 당신의 pod 버전에 대한 좋은 기록을 제공할 것입니다.

결국, 만약 여러분이 촉박한 마감일과 빠듯한 예산을 가지고 있다면, 시간은 본질적입니다. 우리는 엄격한 이념에 시간을 낭비하지 않고, 대신 우리의 삶을 더 효율적으로 만들기 위해 일련의 도구를 사용해야 합니다.

개인적으로 상황에 따라 다릅니다.

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

• 소스가 동일합니다.
• (코코아팟이 없어도) 그대로 바로 만들 수 있습니다.
• 포드가 삭제되더라도 해당 복사본은 남아 있습니다(예, 이러한 현상이 발생할 수 있으며 실제로 발생했습니다). 약간의 변경만 원하는 오래된 프로젝트에서는 새로운 라이브러리를 구현해야 구축할 수 있습니다.
• pods.xcodeproj설정은 소스 제어의 일부이기도 합니다.이것은 예를 들어 프로젝트가 있는 경우를 의미합니다.swift 4하지만 어떤 포드들은 안에 있을 것입니다.swift 3.2아직 업데이트되지 않았기 때문에 이러한 설정이 저장됩니다.그렇지 않으면 레포를 복제한 사람이 오류를 범하게 될 것입니다.
• 하고 프젝트에포삭제실수있행다습니할고하로드를서언을 실행할 수 있습니다.pod install반대로 할 수 없습니다.
• 심지어 코코파드의 저자들도 그것을 추천합니다.

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

마지막에는 여러분이 취하는 접근 방식에 달려 있습니다.

Cocoapods 팀은 다음과 같이 생각합니다.

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

개인적으로 노드를 사용하는 경우 node_modules로 포드를 차단하고 Bower를 사용하는 경우 bower_components로 포드를 차단하고 싶습니다.이는 거의 모든 종속성 관리자에 적용되며 Git 하위 모듈의 원리이기도 합니다.

그러나 특정 종속성의 최신 상태에 대해 정말로 확신하고 싶을 때가 있습니다. 프로젝트 내에서 종속성을 수행하는 방식입니다.물론 그렇게 할 경우 적용되는 몇 가지 단점이 있지만, 이러한 문제는 Cocoapod에만 적용되는 것이 아니라 다른 모든 종속성 관리자에게도 적용됩니다.

아래에는 Cocoapods 팀이 작성한 좋은 장단점 목록과 앞서 언급한 견적의 전문이 있습니다.

코코파드 팀:포드 디렉터리를 소스 제어로 확인해야 합니까?

체크인하지 않을 경우의 장점Pods/버전 제어(주요 순서대로):

0. 커밋을 병합하고 코드 차이를 검토하는 것이 훨씬 쉽습니다.병합은 코드 기반의 일반적인 문제 소스이며, 이를 통해 관련된 항목에만 집중할 수 있습니다.
1. 일부 임의 기여자가 종속성을 직접 편집하고 절대 해서는 안 되는 변경 사항을 확인하는 것은 불가능합니다(그리고 다시 한번 격차가 큰 경우에는 식별하기 어려울 것입니다).을 편집하는 의 것이기 에 매우 입니다.pod install변경사항을 차단할 수 있습니다.
2. 사의불치 간의 Podfile 리고그고.Pods/디렉토리는 팀 동료들 사이에서 더 빨리 발견됩니다.이 는경하우에 .Pods/예를 들어, 의 버전을 업데이트합니다.Podfile하지만 달리는 것을 잊었습니다.pod install합니다.Pods/불일치의 원인을 알아차리는 데 훨씬 더 많은 어려움을 겪을 것입니다.한다면Pods/있지 체인않니다습을 해야 합니다. 항상 실행해야 합니다.pod install어쨌든.
3. 저장소 크기가 더 작습니다.더 작은 바이트 발자국을 갖는 것은 좋지만, 그것은 큰 계획에서 크게 중요하지 않습니다.더 중요한 것은, 레포에 더 많은 것들이 있는 것은 또한 여러분의 인지 부하를 증가시킨다는 것입니다.당신이 보지 말아야 할 것들을 레포에 둘 이유가 없습니다.코드(구현)가 아닌 문서(추상)를 참조하여 무언가가 어떻게 작동하는지 확인하십시오.
4. 다른 사용자가 기여한 정도를 쉽게 식별할 수 있습니다(제공된 코드 행에는 작성하지 않은 종속성이 포함되지 않으므로).
5. JAR 파일,.venv/ 환경) 및 (가상 환경),node_modules/버전 제어에 포함되지 않습니다.만약 우리가 그 질문에 대해 완전히 불가지론자였다면, 체크인하지 않았을 것입니다.Pods선례에 따라 기본값이 됩니다.

체크인을 하지 않을 경우의 단점Pods/

0. 실행해야 합니다.pod install분기를 전환하거나 커밋을 되돌리는 경우.
1. 리포지토리 복제만으로는 프로젝트를 실행할 수 없습니다.도구를 포드도설다실합야니다해를 실행해야 .pod install.
2. 실행하려면 .pod install포드의 출처를 알 수 있어야 합니다.
3. 종속성의 소유자가 패키지를 제거한 경우, 패키지를 사용할 수 없습니다(애초 권장되지 않는 종속성을 사용해서는 안 되지만, 이는 종속성 위생을 더 일찍 수행하도록 강요할 뿐입니다)

요약하자면, 다음을 포함하지 않습니다.Pods디렉터리는 더 이상의 잘못된 관행을 방지하는 가드레일입니다.를 포함하여Pods디렉터리를 사용하면 프로젝트를 더 쉽게 실행할 수 있습니다.저는 후자보다 전자를 더 좋아합니다.애초에 특정 실수를 할 가능성이 없다면 프로젝트에 참여한 모든 신입 사원에게 "하지 말아야 할 일"에 대해 설명할 필요가 없습니다.나는 또한 그것을 위한 별도의 버전 제어를 갖는 것에 대한 생각을 좋아합니다.Pods반대자들을 완화시키는 것입니다.

저에게 가장 큰 관심사는 출처를 입증하는 것입니다.프로젝트를 잠시 유지할 계획인데 코코아 포드가 사라지거나 포드 중 하나의 소스가 다운되면 아카이브에서 새로 구축하려고 하면 완전히 실패하게 됩니다.

이는 정기적인 전체 소스 아카이브를 통해 완화될 수 있습니다.

포드를 확인합니다.

저는 이것이 소프트웨어 개발의 원칙이 되어야 한다고 생각합니다.

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

왜요?

코코아 포드나 다른 외부 라이브러리가 변경되어 문제가 발생할 수 있습니다.또는 이동하거나 이름이 변경되거나 완전히 제거될 수 있습니다.당신은 당신을 위해 물건들을 저장하기 위해 인터넷에 의존할 수 없습니다.랩톱이 고장났을 수 있으며 운영 환경에 심각한 오류가 발생하여 수정해야 합니다.주 개발자가 버스에 치일 수도 있고, 그의 후임자는 서둘러 시작해야 합니다.그리고 마지막 것이 이론적인 예이기를 바라지만 실제로는 제가 함께 했던 스타트업에서 일어난 일입니다.RIP.

현실적으로 모든 종속성을 확인할 수는 없습니다.빌드를 만들 때 사용한 시스템의 이미지를 체크인할 수 없습니다. 정확한 버전의 컴파일러를 체크인할 수 없습니다.등등.현실적인 한계가 있습니다.하지만 당신이 할 수 있는 모든 것을 확인하세요 - 그렇게 하지 않는 것은 당신의 삶을 더 힘들게 만들 뿐입니다.그리고 우리는 그것을 원하지 않습니다.

마지막 단어: 포드는 빌드 아티팩트가 아닙니다.빌드 아티팩트는 빌드에서 생성됩니다.빌드는 포드를 생성하는 것이 아니라 포드를 사용합니다.저는 왜 이것이 논의되어야 하는지조차 잘 모르겠습니다.

TL을 때;DR: 추적할 때Pods/폴더, 프로젝트를 선택하는 것이 더 쉽습니다.추적하지 않으면 팀에서 작업할 때 개선하기가 더 쉽습니다.

가 Cocoapods를 하지만,Pods/디렉토리, 그들은 이러한 장단점을 바탕으로 그것의 여부를 결정하는 것은 개발자들에게 달려 있다고 말합니다: http://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control

개적으로보, ▁the다니▁track를 추적합니다.Pods/당분간 더 이상 작업하지 않을 프로젝트의 폴더입니다.그렇게 하면 어떤 개발자라도 신속하게 그것을 받아들이고 적절한 버전의 코코포드를 사용하여 작업을 계속할 수 있습니다.

저는 가 더 때이 더 합니다.Pods/폴더를 누릅니다.저는 보통 누구나 저와 같은 버전을 사용하여 프로젝트를 설치할 수 있도록 설치할 때 코코팟 라이브러리의 버전을 설정합니다.

, 한때 때 그또.Pods/. 가 실행할 . 모든 개발자는 실행할 때마다 수십 개의 파일이 변경되는 것을 방지하기 위해 동일한 버전의 Cocoapods를 사용해야 합니다.pod install포드를 추가/제거합니다.

결론: 추적할 때Pods/폴더, 프로젝트를 선택하는 것이 더 쉽습니다.추적하지 않으면 개선하기가 더 쉽습니다.

이론적으로, 당신은 포드 디렉토리를 확인해야 합니다.실제로, 그것이 항상 효과가 있는 것은 아닙니다.대부분의 포드는 github 파일의 크기 제한을 훨씬 초과하므로 github을 사용하는 경우 Pods 디렉토리에서 확인하는 데 문제가 발생합니다.

이것을 구성하는 좋은 방법은 "Pods" 디렉터리를 깃 서브모듈/별도 프로젝트로 사용하는 것입니다. 그 이유는 여기에 있습니다.

• 여러 개발자와 작업할 때 프로젝트 레포에 포드가 있으면 사람에 의해 변경된 실제 작업을 확인하는 것이 거의 불가능한 경우(라이브러리용으로 수백에서 수천 개의 파일이 변경되고 실제 프로젝트에서 일부만 변경되었다고 가정할 때) 끌어오기 요청에 매우 큰 차이가 발생할 수 있습니다.

• 저는 도서관을 소유한 사람이 언제든지 도서관을 철거할 수 있고 당신은 본질적으로 SOL이기 때문에 이것 또한 해결됩니다.

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

Pods 디렉토리에서 확인할 경우의 이점

1. 레포를 복제한 후, 이 프로젝트는 기계에 코코아 포드를 설치하지 않아도 즉시 빌드하고 실행할 수 있습니다.포드 설치를 실행할 필요가 없으며 인터넷 연결도 필요하지 않습니다.
2. Pod의 소스(예: GitHub)가 중단되더라도 Pod 아티팩트(코드/라이브러리)는 항상 사용할 수 있습니다.
3. Repo 복제 후 Pod 아티팩트는 원래 설치의 아티팩트와 동일하게 유지됩니다.

포드 디렉터리를 무시할 경우의 이점

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

언급URL : https://stackoverflow.com/questions/9446644/what-goes-into-your-gitignore-if-youre-using-cocoapods