objective-c - studio - pod profile




CocoaPod를 사용한다면.gitignore에 무엇이 들어가게 될까요? (12)

저는 2 달 전부터 iOS 개발을 CocoaPods 의존성 관리를위한 유망한 CocoaPods 라이브러리에 대해 배웠습니다.

나는 개인 프로젝트에서 그것을 시도했다 : Kodi에 나의 Podfile에 의존성을 추가하고, pod install CocoaPodsTest.xcodeproj .

내가 궁금해하는 유일한 것 : 내가 무엇을 체크인 할 것인가, 버전 제어를 위해 무엇을 무시할 것인가? 내가 Podfile 자체와 아마도 .xcworkspace 파일을 체크 인하길 원한다는 것은 분명해 보인다. 하지만 포드 / 디렉토리를 무시합니까? 도로에 생성 될 다른 파일이 있습니까 (다른 종속성을 추가 할 때) .gitignore에도 추가해야합니까?


.gitignore 파일

실제로 .gitignore 제공하는 답변 없으므로 여기에 두 가지 맛이 있습니다.

포드 디렉토리 체크인 ( Benefits )

Xcode / iOS friendly 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/

포드 디렉토리 무시 ( Benefits )

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

# Cocoapods
Pods/

Pods 디렉토리를 체크인했는지 여부에 관계없이 Podfile과 Podfile.lock은 항상 버전 제어하에 있어야합니다.

Pods 가 체크인되지 않은 경우, 귀하의 Pods 은 각 코코아 포드에 대한 명시적인 버전 번호를 요청해야합니다. here Cocoapods.org 토론.


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

Podfile은 특정 태그 또는 각 종속성의 커밋을 참조하므로 포드 자체는 소스보다 중간 빌드 제품과 유사하므로 프로젝트에서 버전 제어가 필요하지 않습니다.


그것은 개인적으로 다음과 같이 달려 있습니다.

포드가 소스 제어하에있는 레포의 일부 여야하는 이유는 무엇입니까? 무시해서는 안됩니다.

  • 출처가 동일하다.
  • 당신은 바로 그것을 (코코아 포드 없이도) 만들 수 있습니다.
  • 포드가 삭제 되더라도 우리는 여전히 복사본을 가지고 있습니다 (예, 이런 일이 발생할 수 있습니다. 작은 프로젝트를 변경하고자하는 오래된 프로젝트에서는 빌드 할 수있는 새 라이브러리를 구현해야합니다).
  • pods.xcodeproj 설정은 소스 컨트롤의 일부이기도합니다. 이것은 예를 들어 프로젝트를 swift 4 가지고 있지만 일부 포드가 아직 업데이트되지 않았기 때문에 swift 3.2 있어야한다는 것을 의미합니다. 이러한 설정은 저장됩니다. 그렇지 않으면 repo를 복제 한 사람은 오류로 끝날 것입니다.
  • 당신은 항상 프로젝트에서 포드를 삭제하고 pod install 실행할 수 있습니다. 그 반대는 할 수 없습니다.
  • Cocoapods의 저자 조차도 그것을 추천합니다.

단점은 저장소가 크고 혼란스러운 diff (주로 팀 구성원 인 경우), 잠재적으로 충돌이 더 많다는 것입니다.


나는 PodfilePodfile.lock 과 함께 Pods 디렉토리를 커밋하여 언제든지 팀원이 언제든지 소스를 체크하고 아무 것도 걱정할 필요가 Podfile 하거나 Podfile.lock 을 작동 시키도록 추가 물건을 만들지 않도록하는 것이 더 좋습니다.

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

불필요한 디렉토리를 무시합니다.

xcuserdata/

나는 일반적으로 클라이언트의 애플 리케이션에서 작동합니다. 이 경우 특정 시점에 모든 개발자가 체크 아웃을 수행하고 빌드하고 실행할 수 있도록하기 위해 저장소에 Pods 디렉토리를 추가합니다.

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

사실, 나는 순수한 사용자의 견해와는 달리 귀하의 질문에 답할 수있는 최선의 사람이 아닐 수도 있다고 생각합니다. https://twitter.com/CocoaPodsOrg 에서이 질문에 대해 트윗 할 것입니다.


나에게 가장 큰 관심사는 앞으로 소스를 교정하는 것입니다. 프로젝트를 오래 동안 끝내고 CocoaPod가 사라지거나 포드 중 하나의 소스가 다운 될 경우 아카이브에서 신선한 것을 만들려고한다면 완전히 운이 없게됩니다.

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


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

포드 디렉토리에서 확인의 이점

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

포드 디렉토리 무시의 이점

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

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

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

포드 디렉토리에서 확인의 이점

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

포드 디렉토리 무시의 이점

  • 소스 제어 저장소가 작아지고 공간을 적게 차지합니다.

  • 모든 포드에 대한 출처 (예 : GitHub)가 제공되는 한 CocoaPod는 일반적으로 동일한 설치를 다시 생성 할 수 있습니다. (기술적으로, Podfile에서 커밋 SHA를 사용하지 않을 때 pod install을 실행하면 동일한 아티팩트가 가져오고 다시 생성된다는 보장이 없습니다. 특히 Podfile에서 zip 파일을 사용할 때 그렇습니다.)

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

Pods 디렉토리를 체크인했는지 여부에 관계없이 Podfile과 Podfile.lock은 항상 버전 제어하에 있어야합니다.


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


저는 도서관에 체크인하지 않은 개발자들의 캠프에 있습니다. 다른 지역에서도 좋은 사본을 얻을 수 있다고 가정합니다. 그래서, 내 .gitignore에는 다음과 같은 CocoaPod 관련 라인이 포함됩니다.

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

그런 다음 도서관의 복사본을 안전한 장소에 보관합니다. 의존성을 저장하기 위해 (프로젝트의 코드 저장소를 사용하는 것보다) 컴파일하는 것이 가장 좋은 방법은 빌드를 아카이브하는 것입니다. 빌드 (예 : Jenkins)에 CI 서버를 사용하면 중요한 빌드를 영구적으로 보관할 수 있습니다. 로컬 Xcode에서 모든 프로덕션 빌드를 수행하는 경우 유지해야하는 빌드에 대해 프로젝트의 아카이브를 가져 오는 습관을 만드십시오. 뭔가 같은 : 1. 제품 -> 아카이브

  1. 배포 ... iOS 앱 스토어에 제출 / 엔터프라이즈 또는 Ad-hoc 배포를 위해 저장 / 무엇이 있습니까?

  2. Finder에서 프로젝트 폴더 공개

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

이것은 CocoaPod를 사용하든 아니든, 바이너리 배포판 (예 : Sparkle, TestFlight와 같은 독점적 인 SDK 등)뿐만 아니라 응용 프로그램을 빌드하는 데 사용 된 전체 프로젝트 및 작업 공간 설정을 포함하여 전체 프로젝트의 빌드 된 이미지를 제공합니다.

업데이트 : 나는 이것에 대한 생각을 바꾸었고 이제 Podfile.lock 을 소스 컨트롤에 적용합니다. 그러나 포드 자체는 유물을 만들어 내고 위에서 설명한 CI 서버 나 보관 프로세스와 같은 다른 방법을 통해 소스 제어 외부에서 관리해야한다고 생각합니다.


포드를 체크인하십시오.

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

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

왜?

CocoaPod 또는 다른 외부 라이브러리가 변경되어 상황이 바뀔 수 있습니다. 또는 이동하거나 이름을 변경하거나 모두 삭제할 수 있습니다. 인터넷에 의존해서 물건을 보관할 수는 없습니다. 노트북이 죽어서 생산에 중대한 버그가있을 수 있습니다. 주요 개발자가 버스에 타격을 입을 수 있으며 교체가 급하게 시작되어야합니다. 그리고 나는 마지막 하나가 이론적 인 예 였지만 실제로는 내가 가진 신생 기업에서 일어났기를 바란다. 삼가 고인의 명복을 빕니다.

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

마지막 단어 : 포드는 인공물을 만들지 않습니다. 빌드 아티팩트는 빌드에서 생성되는 것입니다. 빌드가 포드를 사용하고 생성하지 않습니다. 나는 이것이 왜 논쟁되어야하는지조차 확신하지 못한다.


GitHub의 Objective-C gitignore 를 사용하는 것이 좋습니다. 상세하게는 모범 사례는 다음과 같습니다.

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

자세한 내용은 공식 가이드를 참조하십시오.

source : 저는 @alloy와 같은 CocoaPods 핵심 팀의 멤버입니다.

포드 폴더가 빌드 아티팩트 임에도 불구하고 소스 제어하에 유지하는 것이 더 중요 할 때 고려해야 할 이유가 있습니다.

  • CocoaPod는 패키지 관리자가 아니기 때문에 나중에 라이브러리 원본을 작성자가 삭제할 수 있습니다.
  • 포드 폴더가 소스 컨트롤에 포함되어 있다면 체크 아웃으로 충분하므로 프로젝트를 실행하기 위해 코코아 포드를 설치할 필요가 없습니다.
  • CocoaPods는 여전히 진행 중이며 항상 같은 결과로 이어지지는 않는 옵션이 있습니다 (예 :head:git 옵션은 현재 Podfile.lock 저장된 커밋을 사용하지 않습니다).
  • 중 / 장기간 후에 프로젝트 작업을 재개 할 경우 실패 지점이 적습니다.




cocoapods