Я займаюся розробкою iOS вже пару місяців і щойно дізнався про багатообіцяючу бібліотеку CocoaPods для управління залежностями.

Я спробував це на особистому проекті: додав залежність від ківі до мого Podfile, біг pod install CocoaPodsTest.xcodeprojта вуаля , він спрацював чудово.

Єдине, що мені залишається цікавим, це: що я реєструюсь і що я ігнорую для контролю версій? Здається очевидним, що я хочу перевірити в самому Podfile і, можливо, також .xcworkspace файл; але чи я ігнорую Pods / каталог? Чи є інші файли, які будуть генеровані в дорозі (коли я додаю інші залежності), які я також повинен додати до свого .gitignore?

Особисто я не перевіряю у каталозі та вмісті Pods. Я не можу сказати, що я довгий вік розглядав наслідки, але мої міркування є чимось на кшталт:

Podfile посилається на певний тег або або фіксацію кожної залежності, тому самі Pods можуть бути згенеровані з podfile, але вони більше схожі на проміжний збірний продукт, ніж на джерело і, отже, не потребують контролю версій у моєму проекті.

Я здійснюю свій каталог Pods. Я не згоден, що каталог Pods є артефактом збірки. Насправді я б сказав, що це точно не так. Це частина вашого джерела програми: без нього не буде складено!

Простіше розглядати CocoaPods як інструмент розробника, а не інструмент побудови. Він не будує ваш проект, він просто клонує та встановлює для вас залежність. Не повинно бути встановленим CocoaPods, щоб можна було просто створити ваш проект.

Зробивши CocoaPods залежністю вашої збірки, тепер вам потрібно переконатися, що він доступний скрізь, де вам може знадобитися для створення вашого проекту ... адміністратор команди потребує цього, ваш сервер CI потребує цього. Як правило, ви завжди маєте змогу клонувати джерело сховища та створювати без додаткових зусиль.

Якщо ви не скористаєтеся каталогом Pods, це також призведе до великого головного болю, якщо ви часто перемикаєте гілки. Тепер вам потрібно запускати установку pod кожен раз, коли ви перемикаєте гілки, щоб переконатися, що ваші залежності правильні. Це може бути менше клопоту, оскільки ваші залежності стабілізуються, але на початку проекту це велика прогалина часу.

Отже, що я ігнорую? Нічого. Podfile, файл блокування та каталог Pods все активізуються. Повірте, це позбавить вас багато клопоту. Які мінуси? Трохи більший репо? Не кінець світу.

Рекомендую використовувати gitignore GitHub's Objective-C . Детальніше, найкращі практики:

• Podfile Повинен завжди перебувати під контролем джерела.
• Podfile.lock Повинен завжди перебувати під контролем джерела.
• Робоча область, створена CocoaPods, повинна тримати під контролем джерела.
• Будь-який Pod, на який посилається цей :pathпараметр, повинен утримуватися під контролем джерела.
• ./PodsПапка може перебувати під контролем джерела.

Для отримання додаткової інформації ви можете ознайомитися з офіційним посібником .

Джерело: Я є членом основної команди CocoaPods, як @alloy

Хоча папка Pods є артефактом побудови, є причини, які ви можете врахувати, вирішуючи, чи зберігати її під контролем джерела:

• CocoaPods не є менеджером пакунків, тому авторське джерело бібліотеки може бути видалено в майбутньому автором.
• Якщо папка Pods включена в керування джерелами, не потрібно встановлювати CocoaPods для запуску проекту, оскільки замовлення буде достатньо.
• CocoaPods все ще працює, і є варіанти, які не завжди призводять до однакового результату (наприклад, параметри :headі в :gitданий час не використовують комітети, що зберігаються в Podfile.lock).
• Існує менше пунктів відмови, якщо ви можете відновити роботу над проектом через середній / тривалий проміжок часу.

.gitignore файл

Жодна відповідь насправді не пропонує .gitignore, тому ось два смаки.

Перевірка в каталозі Pods ( Переваги )

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/

Ігнорування каталогу Pods ( переваги )

.gitignore: (додавати до попереднього списку)

# Cocoapods
Pods/

Незалежно від того, чи переходите ви в каталог Pods, Podfile та Podfile.lock завжди повинні знаходитись під контролем версій.

Якщо Podsви не Podfileвстановили прапорець, вам, ймовірно, слід запитати явні номери версій для кожного Cocoapod. Дискусія на Cocoapods.org тут .

Я, як правило, працюю над клієнтами програми. У цьому випадку я додаю також каталог Pods до репо, щоб гарантувати, що в будь-який момент будь-який розробник міг зробити замовлення та створити та запустити.

Якби це власне додаток, я, мабуть, виключив каталог Pods, поки я деякий час не буду над ним працювати.

Насправді, я повинен зробити висновок, що я, можливо, не найкращий чоловік, який би відповів на ваше запитання, порівняно з поглядами чистих користувачів :) Я з цим питанням завітаю з https://twitter.com/CocoaPodsOrg .

Я все перевіряю. ( Pods/і Podfile.lock.)

Я хочу мати змогу клонувати сховище і знати, що все буде так само, як і минулого разу, коли я використовував додаток.

Я вважаю за краще продавати речі, ніж ризикувати, щоб вони мали різні результати, які могли бути спричинені різною версією дорогоцінного каміння, чи хтось переписує історію у сховище Pod тощо.

Відповідь на це дається безпосередньо в документах Cocoapod. Ви можете подивитися на " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control "

Незалежно від того, чи переходите ви у папку Pods, залежить від вас, оскільки робочі процеси різняться від проекту до проекту. Ми рекомендуємо тримати каталог Pods під контролем джерела і не додавати його до свого .gitignore. Але в кінцевому підсумку це рішення залежить від вас:

Переваги перевірки в каталозі Pods

• Після клонування РЕПО проект може негайно створити та запустити, навіть не встановивши на машину CocoaPods. Не потрібно запускати установку pod, і підключення до Інтернету не потрібно.
• Артефакти Pod (код / ​​бібліотеки) завжди доступні, навіть якщо джерело Pod (наприклад, GitHub) повинен знижуватися.
• Артефакти Pod, гарантовано, будуть ідентичними тим, які були в оригінальній установці після клонування репо.

Переваги ігнорування каталогу Pods

• Репо управління джерела буде менше і займе менше місця.

• Поки джерела (наприклад, GitHub) для всіх Pods є доступними, CocoaPods, як правило, може відтворити одну і ту ж установку. (Технічно немає гарантії, що запущена установка pod отримає та відтворить ідентичні артефакти, коли не використовується SHA-файлу для передачі файлів у Podfile. Це особливо актуально при використанні поштових файлів у Podfile.)

• При виконанні операцій з управління джерелами не повинно виникнути конфліктів, наприклад, об'єднання гілок з різними версіями Pod.

Незалежно від того, чи переходите ви в каталог Pods, Podfile та Podfile.lock завжди повинні знаходитись під контролем версій.

Я в таборі розробників, які не перевіряють бібліотеки, припускаючи, що у нас є хороша копія в іншому місці. Отже, у свій .gitignore я включаю наступні рядки, характерні для CocoaPods:

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

Тоді я переконуюсь, що у нас є копія бібліотек у безпечному місці. Замість того, щоб (неправильно) використовувати сховище коду проекту для зберігання залежностей (складених чи ні), я думаю, що найкращий спосіб зробити це - архівувати збірки. Якщо ви використовуєте сервер CI для своїх збірок (наприклад, Jenkins), ви можете назавжди архівувати будь-які важливі для вас збірки. Якщо ви робите всі виробничі побудови у своєму локальному Xcode, створіть звичку брати архів свого проекту для будь-яких збірок, які вам потрібно зберегти. Щось на кшталт: 1. Продукт -> Архів

1. Поширюйте ... Надішліть у магазині додатків iOS / Збережіть для корпоративних чи спеціальних розгорнень / iOS

2. Розкрийте папку свого проекту в Finder

3. Клацніть правою кнопкою миші та стисніть "Що б не було"

Це забезпечує вбудований образ усього проекту, включаючи повний параметр проекту та робочої області, що використовується для створення програми, а також бінарні дистрибутиви (наприклад, Sparkle, фірмові SDK, такі як TestFlight тощо), незалежно від того, використовують вони CocoaPods чи ні.

Оновлення: Я змінив свою думку з цього приводу і тепер здійснюю Podfile.lockконтроль над джерелом. Однак я все ще вважаю, що самі стручки - це артефакти, і ними слід керувати як поза джерелом управління, за допомогою іншого методу, наприклад, вашого сервера CI або архівного процесу, як я описав вище.

Я вважаю за краще створювати Podsкаталог разом із цим Podfileі Podfile.lockпереконуюсь, що хтось із моєї команди може перевірити джерело в будь-який час, і їм не доведеться нічого турбуватися чи робити додаткові речі, щоб він працював.

Це також допомагає в сценарії, коли ви виправили помилку в одній з стручків або змінили деяку поведінку відповідно до ваших потреб, але ці зміни не будуть доступні на інших машинах, якщо їх не буде здійснено.

І ігнорувати непотрібні каталоги:

xcuserdata/

Треба сказати, я шанувальник привласнення Pods до сховища. Перейшовши за вказаним посиланням, ви отримаєте хороший файл .gitignore, щоб отримати ваші Xcode-проекти для iOS, щоб дозволити Pods, але також легко вилучити їх, якщо ви цього хочете: https://github.com/github/gitignore/ крапля / майстер / Objective-C.gitignore

Мої міркування щодо того, щоб бути шанувальником додавання Pods до сховища, є однією з фундаментальних причин, на яку, схоже, ніхто не береться, що станеться, якщо бібліотека, від якої так залежить наш проект, раптово видаляється з Інтернету?

• Можливо, хост вирішив, що вони більше не хочуть залишати свій обліковий запис GitHub відкритим
• Ще один момент: що станеться, якщо URL-адреса сховища зміниться? Скажімо, людина, яка обслуговує Pod із свого облікового запису GitHub, вирішує представити себе під іншою ручкою - ваші URL-адреси Pods зірвуться.
• Нарешті ще один момент. Скажіть, якщо ви такий розробник, як я, який робить багато кодування під час перельоту між країнами. Я швидко натягую на "майстер" гілку, встановлюю стручку на цій гілці, сидячи в аеропорту і все готова до майбутнього 8-годинного польоту. Я отримую 3 години свого польоту і розумію, що мені потрібно перейти до іншої гілки .... 'DOH' - відсутні дані про Pod, які доступні лише у гілці 'master'.

Примітка. Зверніть увагу, що "головна" гілка для розробки - це лише приклади. Очевидно, що "майстерні" гілки в системах управління версіями повинні бути чистими та розгорнутими / складатися в будь-який час

Я думаю, що з цих моментів знімки у ваших сховищах коду, безумовно, кращі, ніж суворо щодо розміру сховища. І як уже згадувалося, файл podfile.lock - хоча керована версія надасть вам гарну історію ваших версій Pod.

Зрештою, якщо у вас є надзвичайний термін, щільний бюджет, час є суттєвим - нам потрібно бути максимально винахідливим і не витрачати час на суворі ідеології, а натомість використовувати набір інструментів для спільної роботи - щоб полегшити наше життя більш ефективним.

Зрештою, від вас залежить підхід.

Про це думає команда Cocoapods:

Незалежно від того, чи переходите ви у папку Pods, залежить від вас, оскільки робочі процеси різняться від проекту до проекту. Ми рекомендуємо тримати каталог Pods під контролем джерела і не додавати його до свого .gitignore. Але в кінцевому підсумку це рішення залежить від вас.

Особисто я хотів би зберегти Pods , як node_modules, якщо я використовував Node або bower_components, якщо я використовував Bower . Це стосується майже будь-якого диспетчера залежностей, і це також філософія, що стоїть за підмодулями git .

Однак іноді, можливо, ви хочете бути впевнені в сучасності певної залежності, таким чином, ви маєте власну залежність у своєму проекті. Звичайно, є кілька недоліків, які застосовуються, якщо ви це зробите, але питання стосуються не лише Cocoapods, це стосується будь-якого менеджера із залежностей там.

Нижче наводиться хороший список плюсів / мінусів, складений командою Cocoapods, та повний текст цитати, згаданої раніше.

Команда Cocoapods: Чи слід перевірити каталог Pods на контроль джерел?

Це особисто залежить:

Чому стручки повинні бути частиною репо (під контролем джерел) і не слід їх ігнорувати

• Джерело тотожне
• Ви можете побудувати його як завжди (навіть без кокаподів)
• Навіть якщо струк буде видалено, у нас все ще є його копія (Так, це може статися і це було. У старому проекті, де ви хочете лише невелику зміну, вам потрібно буде впровадити нову бібліотеку, щоб мати можливість навіть побудувати).
• pods.xcodeprojПараметри також є частиною керування джерелом. Це означає, наприклад, якщо у вас є проект swift 4, але деякі стручки повинні бути, swift 3.2оскільки вони ще не оновлені, ці налаштування будуть збережені. Інакше той, хто клонував репо, закінчився б помилками.
• Ви завжди можете видалити стручки з проекту та запустити pod install, навпаки зробити не можна.
• Навіть автори кокаподів рекомендують це.

Деякі мінуси: більший сховище, незрозумілі розбіжності (переважно для членів команди), потенційно більше конфліктів.

Для мене найбільше турбує майбутнє підтвердження вашого джерела. Якщо ви плануєте, щоб ваш проект тривав деякий час, і CocoaPods коли-небудь згасає або джерело одного з стручків знижується, вам зовсім не пощастить, якщо ви намагаєтеся створити свіжий з архіву.

Це може бути пом’якшене періодичними архівами з повним джерелом.

Заїзд у Підс.

Я думаю, що це має бути принципом розробки програмного забезпечення

• Усі склади повинні бути відтвореними
• Єдиний спосіб забезпечити відтворення конструкцій - це контролювати всі залежності; Тому перевірка всіх залежностей є обов'язковою.
• Новий розробник, починаючи з нуля, повинен мати можливість перевірити ваш проект і почати працювати.

Чому?

CocoaPods або будь-які інші зовнішні бібліотеки можуть змінитися, що може порушити ситуацію. Або вони можуть переміщатися, або перейменовуватися, або видалятися взагалі. Ви не можете розраховувати на Інтернет, щоб зберігати речі для вас. Можливо, ваш ноутбук загинув, і у виробництві є критична помилка, яку потрібно виправити. Головний розробник може потрапити в автобус, і його заміна повинна запускатись поспіхом. І я хотів би, щоб останній був теоретичним прикладом, але насправді це сталося при запуску, з яким я був. RIP.

Тепер, реально, ви не можете реально перевірити ВСІ залежності. Ви не можете перевірити зображення машини, яку ви використовували для створення збірок; Ви не можете перевірити точну версію компілятора. І так далі. Існують реалістичні межі. Але перевірте все, що можете - не робити цього просто ускладнює ваше життя. І ми цього не хочемо.

Заключне слово: стручки не будують артефакти. Створіть артефакти - це те, що отримується від вашої збірки. Ваша збірка використовує Pods, а не генерує їх. Я навіть не впевнений, чому це потрібно обговорювати.

Плюси не заїзду Pods/до контролю версій (у суб'єктивному порядку важливості):

1. Значно простіше об'єднати коміти, і код огляду відрізняється. Об’єднання є загальним джерелом проблем у кодовій базі, і це дозволяє зосередитись лише на релевантних речах.
2. Деяким випадковим дописувачам неможливо відредагувати залежності і перевірити зміни, які вони ніколи не повинні робити (і знову важко буде визначити, чи різниця є масовою). Редагування залежностей є дуже поганою практикою, оскільки майбутнє pod installможе призвести до змін.
3. Розбіжності між каталогом Podfileта Pods/каталогом виявляються швидше серед товаришів по команді. Якщо ви зареєструєтесь Pods/і, наприклад, оновите версію в програмі Podfile, але забудете запустити pod installабо зареєструвати зміни Pods/, вам доведеться набагато складніше помітити джерело невідповідності. Якщо Pods/це не встановлено, завжди потрібно працювати pod install.
4. Менший розмір репо. Маючи менший байт-слід, це приємно, але це не має великого значення у грандіозній схемі. Що ще важливіше: маючи більше речей у репо, також збільшується ваше пізнавальне навантаження. Немає жодних причин, щоб у репо було речі, на які ви не повинні дивитись. Зверніться до документації (абстракції), щоб знати, як щось працює, а не за кодом (реалізація).
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 # повинен-i-check-the-pods-directory-into-source-control

Особисто я зазвичай відстежую Pods/папку лише для проектів, над якими я не буду працювати деякий час. Таким чином, будь-який розробник може швидко забрати з нього і продовжити роботу, використовуючи належну версію кокаподів.

З іншого боку, я думаю, що історія фіксації стає чистішою, і її простіше злити код і переглянути код іншої людини, коли ви не відстежуєте Pods/папку. Я зазвичай встановлюю версію бібліотеки cocoapod, коли я встановлюю її, щоб переконатися, що хтось може встановити проект, використовуючи ті самі версії, що і я.

Крім того, під Pods/час відстеження каталогу всі розробники повинні використовувати ту саму версію Cocoapods, щоб запобігти зміні десятків файлів кожного разу, коли ми запускаємо pod installдля додавання / видалення стручка.

Підсумок : під час відстеження Pods/папки проект легше підібрати. Якщо ви не відстежуєте це, простіше покращити роботу.

Схоже, хорошим способом структурування цього справді було б мати каталог "Pods" як підмодуль git / окремий проект, ось чому.

• Наявність стручків у проекті репо, під час роботи з кількома розробниками може спричинити ДУЖЕ ВЕЛИЧЕЗНІ розбіжності у запитах на витяг, де майже неможливо побачити фактичну роботу, яку змінили люди (подумайте, що декілька сотень і тисяч файлів змінено для бібліотек, і лише в реальному проекті мало змінених).

• Я бачу питання про те, щоб нічого не робити на git, оскільки людина, яка володіє бібліотекою, може її зняти в будь-який час, і ви, по суті, є SOL, це також вирішує це.

Незалежно від того, чи переходите ви у папку Pods, залежить від вас, оскільки робочі процеси різняться від проекту до проекту. Ми рекомендуємо тримати каталог Pods під контролем джерела і не додавати його до свого .gitignore. Але в кінцевому підсумку це рішення залежить від вас:

Переваги перевірки в каталозі Pods

1. Після клонування РЕПО проект може негайно створити та запустити, навіть не встановивши на машину CocoaPods. Не потрібно запускати установку pod, і підключення до Інтернету не потрібно.
2. Артефакти Pod (код / ​​бібліотеки) завжди доступні, навіть якщо джерело Pod (наприклад, GitHub) повинен знижуватися.
3. Артефакти Pod, гарантовано, будуть ідентичними тим, які були в оригінальній установці після клонування репо.

Переваги ігнорування каталогу Pods

1. Репо управління джерела буде менше і займе менше місця. Поки джерела (наприклад, GitHub) для всіх Pods є доступними, CocoaPods, як правило, зможе відтворити одну і ту ж установку. (Технічно немає гарантії, що запущена установка pod отримає та відтворить однакові артефакти, коли не використовується команда SHA у Podfile . Особливо це стосується використання zip-файлів у Podfile.)
2. При виконанні операцій з управління джерелами не повинно виникнути конфліктів, наприклад, об'єднання гілок з різними версіями Pod. Незалежно від того, чи переходите ви в каталог Pods, Podfile та Podfile.lock завжди повинні знаходитись під контролем версій.