Ответ 1

Лично я не проверяю каталог и содержимое Pods. Я не могу сказать, что я долгое время рассматривал последствия, но мои рассуждения - это что-то вроде:

Подфайл ссылается на конкретный тег или или на фиксацию каждой зависимости, поэтому сами Pod могут быть сгенерированы из podfile, и они более похожи на продукт промежуточной сборки, чем источник, и, следовательно, не нуждаются в управлении версиями в мой проект.

Ответ 2

Я фиксирую каталог Pods. Я не согласен с тем, что каталог Pods является артефактом сборки. На самом деле я бы сказал, что это определенно не так. Это часть вашего источника приложения: он не будет строить без него!

Легче думать о CocoaPods как инструменте разработчика, а не о инструменте построения. Он не создает ваш проект, он просто клонирует и устанавливает ваши зависимости для вас. Не нужно устанавливать CocoaPods, чтобы иметь возможность просто создавать ваш проект.

Из-за того, что CocoaPods зависит от вашей сборки, теперь вам нужно убедиться, что она доступна везде, где вам может понадобиться для создания вашего проекта... администратору этой команды это нужно, вашему CI-серверу это нужно. Вы, как правило, всегда сможете клонировать исходный репозиторий и строить без каких-либо дополнительных усилий.

Не фиксируя каталог Pods, вы также создаете массированную головную боль, если вы часто переключаете ветки. Теперь вам нужно запустить pod install каждый раз, когда вы переключаете ветки, чтобы убедиться, что ваши зависимости верны. Это может быть меньше хлопот, так как ваши зависимости стабилизируются, но в начале проекта это массивное время.

Итак, что я игнорирую? Ничего. Подфайл, файл блокировки и каталог Pods все передаются. Поверьте мне, это сэкономит вам много хлопот. Каковы минусы? Немного больше репо? Не конец света.

Ответ 3

Я рекомендую использовать GitHubs Objective-C gitignore. В частности, лучшие практики:

• Podfile должен всегда находиться под контролем источника.
• Podfile.lock должен всегда находиться под контролем источника.
• Рабочее пространство, созданное CocoaPods должно находиться под контролем источника.
• Любая ссылка, связанная с опцией :path должна находиться под контролем источника.
• Папка ./Pods может находиться под контролем источника.

Для получения дополнительной информации вы можете обратиться к официальному руководству .

source: Im является членом основной команды CocoaPods, например @alloy

Хотя папка Pods является артефактом сборки, есть причины, которые вы можете учесть, решив, чтобы сохранить ее под контролем источника:

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

Ответ 4

Я вообще работаю над приложениями клиентов. В этом случае я также добавляю каталог Pods в репо, чтобы гарантировать, что в любой момент времени любой разработчик сможет выполнить проверку и построить и запустить.

Если бы это было наше приложение, я бы, вероятно, исключил каталог Pods, пока я не буду работать над ним некоторое время.

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

Ответ 5

.gitignore файл

Нет ответа на самом деле предлагает .gitignore, так что вот два варианта.

Проверка в каталоге Pods (Benefits)

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 (Benefits)

.gitignore: (добавьте в предыдущий список)

# Cocoapods
Pods/

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

Если Pods не зарегистрировано, ваш Podfile должен, вероятно, запрашивать явные номера версий для каждого Cocoapod. Обсуждение Cocoapods.org здесь.

Ответ 6

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

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

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

Ответ 7

Ответ на это дан непосредственно в документах Cocoapod. Вы можете посмотреть на " http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control"

Независимо от того, просматриваете ли вы свою папку "Под", зависит от вас, так как рабочие процессы варьируются от проекта к проекту. Мы рекомендуем сохранить Pods под контролем источника и не добавляйте его в свой .gitignore. Но в конечном итоге это решение зависит от вас:

Преимущества проверки в каталоге Pods

• После клонирования репо проект может сразу создавать и запускать, даже без установки CocoaPods на машине. Здесь нет необходимо выполнить установку pod, и не требуется подключение к Интернету.
• Артефакты Pod (код/​​библиотеки) всегда доступны, даже если источник Pod (например, GitHub) должен был спуститься.
• Артефакты Pod гарантированно идентичны тем, которые были в оригинальной установке после клонирования репо.

Преимущества игнорирования каталога Pods

• Репозиторий управления версиями будет меньше и займет меньше места.

• Пока доступны источники (например, GitHub) для всех Pods, CocoaPods, как правило, может воссоздать одну и ту же установку. (Технически нет никакой гарантии, что запуск установки pod будет получен и воссоздать идентичные артефакты, если не использовать SHA фиксации в Podfile. Это особенно актуально при использовании zip файлов в подфайле.)

• Не будет никаких конфликтов при работе с операциями управления версиями, например, слияния ветвей с разными Pod версии.

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

Ответ 8

Я в лагере разработчиков, которые не проверяют библиотеки, предполагая, что у нас есть хорошая копия, доступная в другом месте. Итак, в моем .gitignore я включаю следующие строки, специфичные для CocoaPods:

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

Затем я удостоверяюсь, что у нас есть копия библиотек в безопасном месте. Вместо (неверно) использовать репозиторий кода проекта для хранения зависимостей (скомпилированных или нет), я считаю, что лучший способ сделать это - архивировать сборки. Если вы используете CI-сервер для своих сборок (например, Jenkins), вы можете навсегда архивировать любые важные для вас сборки. Если вы делаете все свои сборки в своем локальном Xcode, привыкните брать архив своего проекта для любых сборок, которые вам нужно сохранить. Что-то вроде: 1. Продукт → Архив

• Распространять... Отправить в iOS App Store/Сохранить для Enterprise или Ad-hoc Развертывание/что у вас

• Откройте папку проекта в Finder

• Щелкните правой кнопкой мыши и сжимайте "WhateverProject"

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

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

Ответ 9

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

Это также помогает в сценарии, в котором вы исправили ошибку внутри одного из модулей или изменили какое-либо поведение в соответствии с вашими потребностями, но эти изменения не будут доступны на других компьютерах, если они не были зафиксированы.

И игнорировать ненужные каталоги:

xcuserdata/

Ответ 10

Я должен сказать, что я поклонник фиксации Pods в репозитории. Следуя упомянутой ссылке, вы получите хороший .gitignore файл, чтобы получить ваши проекты Xcode для iOS, чтобы разрешить Pods, но также и для вас, чтобы вы легко их исключили, если хотите: https://github.com/github/gitignore/blob/master/Objective-C.gitignore

Мое рассуждение о том, чтобы быть поклонником добавления Pods в репозиторий, является одной из основополагающих причин, по которым никто, кажется, не набирает обороты, что происходит, если библиотека, в которой наш проект так зависит, внезапно удаляется из Интернета?

• Может быть, хозяин решает, что они больше не хотят держать свой GitHub открытие учетной записи Что произойдет, если библиотека скажет несколько лет (например, старше 5 лет) существует высокий риск проект может быть недоступен в источнике
• Еще один момент, что произойдет, если URL-адрес репозитория изменения? Допустим, человек, обслуживающий Pod от их GitHub учет, решает представить себя под другой ручкой - ваши URL-адреса Pods будут сломаться.
• Наконец, еще один момент. Скажите, если вы такой разработчик, как я, который много делает кодирования при полете между странами. Я быстро натягиваю ветвь "хозяин", выполните установку на этой ветке, сидя в аэропорту и у меня все готово к предстоящим 8 часам рейс. Я получаю 3 часа в свой полет и понимаю, что мне нужно переключиться на другая ветка.... "DOH" - отсутствует информация о Pod, доступная только на ветке "master".

NB... обратите внимание, что ветвь "master" для разработки - это только примеры, очевидно, "ведущие" ветки в системах управления версиями, должны быть очищены и разворачиваться/создаваться в любое время

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

В конце дня, если у вас есть срочный срок, жесткий бюджет, время имеет сущность - нам нужно быть максимально находчивыми и не тратить время на строгие идеологии, а вместо этого использовать набор инструментов работать вместе - сделать нашу жизнь более эффективной.

Ответ 11

В конце вам подходит подход, который вы делаете.

Это то, о чем думает команда Cocoapods:

Независимо от того, просматриваете ли вы свою папку "Под", зависит от вас, так как рабочие процессы варьируются от проекта к проекту. Мы рекомендуем сохранить Pods под контролем источника и не добавляйте его в свой .gitignore. Но в конечном итоге это решение зависит от вас.

Лично я хотел бы оставить Pods в качестве node_modules, если бы я использовал Node или bower_components, если бы использовал Bower. Это применимо практически для любого менеджера зависимостей, а также является основой подмодулей git.

Однако иногда бывает, что вы можете быть действительно уверены в состоянии определенной зависимости, таким образом вы несете свою зависимость в своем проекте. Конечно, есть несколько недостатков, которые применяются, если вы это делаете, но проблемы относятся не только к Cocoapods, но и к любому диспетчеру зависимостей.

Ниже приведен хороший список про/против, сделанный командой Cocoapods, и полный текст цитаты, упомянутой ранее.

Команда Cocoapods: следует ли проверять каталог Pods в исходном элементе управления?

Ответ 12

Это зависит, лично:

Почему контейнеры должны быть частью репо (под контролем источника) и не должны игнорироваться

• Источник идентичен
• Вы можете построить его сразу, как есть (даже без коко-каподов)
• Даже если pod удален, у нас все еще есть его копия (да, это может произойти, и это произошло. В старом проекте, где вам нужно только небольшое изменение, вам нужно будет внедрить новую библиотеку, чтобы иметь возможность даже строить).
• Настройки pods.xcodeproj являются частью элемента управления. Это означает, например, если у вас есть проект в swift 4, но некоторые стручки должны быть в swift 3.2 потому что они еще не обновлены, эти настройки будут сохранены. В противном случае тот, кто клонировал репо, закончил бы ошибками.
• Вы всегда можете удалить контейнеры из проекта и запустить pod install, противоположное не может быть сделано.
• Даже авторы Cocoapods рекомендуют это.

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

Ответ 13

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

Это можно было бы смягчить с помощью периодических полных архивов источников.

Ответ 14

Зайдите в Pods.

Я думаю, что это должен быть принцип разработки программного обеспечения

• Все сборки должны быть воспроизводимыми
• Единственный способ обеспечить сборку воспроизводимый должен контролировать все зависимости; проверка всех следовательно, необходимо.
• Новый разработчик, начинающий с нуля, сможет проверить ваш проект и начать работу.

Почему?

CocoaPods или любые другие внешние библиотеки могут измениться, что может нарушить работу. Или они могут перемещаться или переименовываться или вообще удаляться. Вы не можете полагаться на интернет, чтобы хранить вещи для вас. Ваш ноутбук, возможно, умер, и есть критическая ошибка в производстве, которая должна быть исправлена. Главный разработчик может попасть в автобус, и его замена должна начать спешить. И я желаю, чтобы последний был теоретическим примером, но это действительно произошло при запуске, с которым я был. RIP.

Теперь, реалистично, вы не можете проверить все зависимости. Вы не можете проверить изображение машины, которую вы использовали для создания сборок; вы не можете проверить точную версию компилятора. И так далее. Существуют реальные пределы. Но проверьте все, что вы можете - не делая этого, просто делает вашу жизнь труднее. И мы этого не хотим.

Заключительное слово: Pods не создают артефакты. Построить артефакты - это то, что генерируется из ваших сборников. Ваша сборка использует Pods, а не создает их. Я даже не знаю, почему это нужно обсуждать.

Ответ 15

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

• Наличие в вашем проекте репо, когда вы работаете с несколькими разработчиками, может привести к тому, что ОЧЕНЬ БОЛЬШОЙ разницы в запросах на тяну, где практически невозможно увидеть фактическую работу, которая была изменена людьми (думаю, несколько сотен или тысяч файлов изменены для библиотек и только несколько изменений в самом проекте).

• Я вижу проблему не совершать ничего с git, так как человек, владеющий библиотекой, может снять его в любое время, и вы, по сути, SOL, это также решает.

Ответ 16

Независимо от того, просматриваете ли вы свою папку "Подписки", зависит от вас, так как рабочие процессы варьируются от проекта к проекту. Мы рекомендуем хранить каталог Pods под контролем источника и не добавлять его в свой .gitignore. Но в конечном итоге это решение зависит от вас:

Преимущества проверки в каталоге Pods

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

Преимущества игнорирования каталога Pods

• Репозиторий управления версиями будет меньше и займет меньше места. Пока доступны источники (например, GitHub) для всех Pods, CocoaPods, как правило, может воссоздать одну и ту же установку. (Технически нет никакой гарантии, что запуск установки pod будет извлекать и воссоздавать идентичные артефакты, если не использовать SHA фиксации в подфайле Это особенно актуально при использовании zip файлов в подфайле.)
• При выполнении операций управления версиями конфликтов, таких как объединение ветвей с разными версиями Pod, не будет никаких конфликтов. Независимо от того, просматриваете ли вы каталог Pods, Podfile и Podfile.lock всегда должны находиться под контролем версий.

Ответ 17

В теории вы должны проверить каталог Pods. На практике это не всегда будет работать. Многие контейнеры значительно превышают ограничение на размер файлов github, поэтому, если вы используете github, у вас будет проблема проверки в каталоге Pods.

Ответ 18

Плюсы не проверки в Pods/ для контроля версий (в субъективном порядке важности):

1. Гораздо проще объединять коммиты и просматривать различия кода. Слияние - это распространенный источник проблем в кодовой базе, и это позволяет вам сосредоточиться только на важных вещах.
2. Некоторый случайный участник не может самостоятельно редактировать зависимости и проверять изменения, которые они никогда не должны делать (и опять-таки было бы трудно определить, является ли разница массивной). Редактирование зависимостей - очень плохая практика, потому что будущая pod install может заблокировать изменения.
3. Расхождения между Podfile и Podfile Pods/ обнаруживаются быстрее среди товарищей по команде. Если вы зарегистрируетесь в Pods/ и, например, обновите версию в Podfile, но забудете запустить pod install или зарегистрировать изменения в Pods/, вам будет гораздо сложнее заметить источник несоответствия. Если Pods/ не зарегистрирован, вам всегда нужно запускать pod install.
4. Меньший размер репо. Хорошо иметь меньший размер байта, но в общей схеме это не имеет большого значения. Что еще более важно: наличие большего количества вещей в репо также увеличивает вашу когнитивную нагрузку. Нет никаких причин иметь в репо то, на что не стоит смотреть. Обратитесь к документации (абстракция), чтобы узнать, как что-то работает, а не в коде (реализации).
5. Проще различить, какой вклад вносит кто-то (поскольку его строки кода не содержат зависимостей, которые они не написали)
6. JAR файлы, .venv/ (виртуальные среды) и node_modules/ никогда не включаются в управление версиями. Если бы мы были абсолютно агностики по этому вопросу, не проверка в Pods будет по умолчанию на основе прецедента.

Минусы не проверка в Pods/

1. Вы должны запустить pod install при переключении веток или отмене коммитов.
2. Вы не можете запустить проект, просто клонировав хранилище. Вы должны установить инструмент pod, затем запустить pod install.
3. У вас должно быть подключение к Интернету, чтобы запустить pod install, и источник модулей должен быть доступен.
4. Если владелец зависимости удаляет свой пакет, у вас проблемы.

Таким образом, не включая каталог Pods является ограждением от более плохих практик. Включение каталога Pods облегчает запуск проекта. Я предпочитаю первое, а не второе. Вам не нужно будет опрашивать каждого нового человека в проекте о том, "что не следует делать", если нет возможности совершить определенные ошибки в первую очередь. Мне также нравится идея иметь отдельный контроль версий для Pods который облегчает минусы.