Что входит в ваш .gitignore, если вы используете CocoaPods?

388

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

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

Единственное, что меня интересует: что мне регистрировать и что игнорировать для контроля версий? Кажется очевидным, что я хочу проверить сам файл Podfile и, возможно, файл .xcworkspace; но я игнорирую каталог Pods /? Есть ли другие файлы, которые будут сгенерированы в будущем (когда я добавлю другие зависимости), которые я также должен добавить в свой .gitignore?

Дэн Тао
источник

Ответы:

261

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

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

Мэтт косилка
источник
70
Возможно, стоит упомянуть, что проект CocoaPods игнорирует каталог Pods в примере .
Джошепуорт
34
Я хотел бы рассмотреть возможность добавления файла Podfile.lock, потому что тогда вы записываете именно те версии библиотек, которые вы использовали для конкретной сборки, и можете воспроизводить их именно для других членов команды. Необходимость спросить «какую версию X вы используете» может быть очень раздражающей. Вот хорошее обсуждение рубинового эквивалента Gemfile
Мэтт Коннолли
12
Я не понимаю, почему вы фиксируете Podfile.lock, разве вы не должны быть более точными в своем Podfile о том, от каких именно версий вы зависите? Что я не понимаю?
Майкл Балтакс
9
Вот как я это вижу: если в вашем Podfile указаны точные версии каждого модуля, то единственный способ получить обновления - это узнать, что обновления существуют, и указать их вручную. Это может быть предпочтительным для популярного или критически важного приложения. Для более ранней разработки важные обновления гораздо проще получить, если вы просто разглядите Podfile.lock, когда он будет обновлен, а затем решите, хотите ли вы обновления, что вы, вероятно, делаете большую часть времени.
Давидковский
43
Важно упомянуть Podfile.lock: Cocoapods выдает его как рекомендованное для контроля версий.
cbowns
383

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

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

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

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

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

Люк Редпат
источник
33
Это определенно способ использовать CocoaPods. Это не только часть вашего исходного кода, потому что вы не можете построить без него, но и ваше «основное приложение» также часто тесно связано с кодом в CocoaPods. Для управления версиями очень важно точно знать, какая версия модуля используется, и простое использование Lockfile не приводит к ее сокращению.
Джошуа Гросс
35
Проще при переключении веток и при возврате во времени ... Это весомый аргумент.
MonsieurDart
5
Да, я мог бы подробнее остановиться на этом, но для меня фиксация в вашем репо представляет собой моментальный снимок вашего источника, и если вы не фиксируете каталог Pods, большая часть этого снимка отсутствует. Вы можете смягчить это, указав конкретные версии своих модулей, но также учтите это ... если вы обновите один из ваших модулей, если ваши модули находятся в вашем репо, то это обновление будет зафиксировано в коммите и будет полностью изменяемым. Если обновление Pod вызывает ошибку, вы можете намного легче понять, почему, поскольку основное изменение фиксируется в вашем собственном репо.
Люк Редпат
5
Я думаю, теперь ясно, что это вопрос личного вкуса. Такие люди, как Симус, теперь поляризуют дебаты ... на самом деле несправедливо утверждать, что если вы не включите Podsкаталог, это вызовет у вас боль, так как его регистрация также сопряжена с рядом проблем. Например, разработчик изменяет версию зависимости в, Podfileне забывая проверять обновленные источники в Pods. Закон Мэрфи. pod installкаждый раз, когда вы переключаете ветку, вы тратите драгоценные ... десятки секунд - но это полностью устраняет этот класс проблем.
фатухоку
14
It won't build without it!С таким же успехом вы могли бы совершить XCode
Sourabh
155

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

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

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

источник: я являюсь членом основной команды CocoaPods, как @alloy


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

  • CocoaPods не является менеджером пакетов, поэтому в будущем автор может удалить исходный источник библиотеки.
  • Если папка Pods включена в систему контроля версий, нет необходимости устанавливать CocoaPods для запуска проекта, так как проверки будет достаточно.
  • CocoaPods все еще находится в стадии разработки, и есть опции, которые не всегда приводят к одному и тому же результату (например, опции :headи в :gitнастоящее время не используют коммиты, хранящиеся в Podfile.lock).
  • Существует меньше точек отказа, если вы можете возобновить работу над проектом через средний / длительный промежуток времени.
Fabio
источник
5
Зачем хранить файл рабочей области? В любом случае он генерируется Cocoapods.
фатухоку
1
@fatuhoku Для Cocoapods-слепых тестовых серверов с непрерывной интеграцией, по моему опыту. Я проверяю все это, потому что у меня нет доступа к сценарию сборки для моего хоста CI (бизнес-правила), и я рассматриваю CocoaPods как инструмент разработчика, а не систему сборки или менеджер пакетов.
codepoet
1
Папка ./Pod НЕ должна находиться под контролем исходного кода (она создается автоматически) CocoaPods. Папка Pods - это артефакт процесса сборки. Рабочее пространство также можно удалить из системы контроля версий, если в нем нет других проектов, не управляемых с помощью CocoaPods.
Влад
Я думаю, что это должно быть проверено, потому что каждый раз, когда я делаю тягу, каждый раз, когда я делаю пул, делать установку модуля.
MSCW
45

файл .gitignore

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


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

Git игнорирует Xcode / iOS, пропуская системные файлы 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 здесь .

SwiftArchitect
источник
38

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

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

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

сплав
источник
Я бы также повторил это. Вы можете использовать CocoaPods без необходимости его использования другими разработчиками (хотя они должны это делать), установив флажок в папке Pods. Как только CocoaPods станет вездесущим, стручки будут похожи на драгоценные камни, вы отметите их в тех же случаях, что и «продавцы» рубиновых драгоценных камней.
Бен Шейрман
2
Я думаю, нужно также учитывать, что иногда утилиты pods или pod (хорошая версия) могут быть недоступны. Более того, если два пользователя с разными версиями утилиты pod запускают утилиту для одного и того же Podspec, выходные данные могут отличаться.
Адриан
1
Оформление заказа, сборка и запуск является наиболее важным фактором. Почему вы делаете свою сборку и способность строить зависимыми от каких-либо внешних факторов? Я проверяю все стручки. Вы можете сэкономить другим разработчикам (или себе в будущем) часы на поиск нужных модулей. Я также не вижу никаких недостатков в их проверке.
n13
18

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

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

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

funroll
источник
4
Еще одна приятная вещь, связанная с этим, - после обновления вы можете посмотреть различие перед регистрацией и посмотреть, какие именно файлы в модулях изменились.
funroll
2
Кроме того, ваш проект не требует, чтобы у всех ваших разработчиков были установлены CocoaPods (что может быть полезно, если вы хотите контролировать, кто / как добавляет и обновляет зависимости).
Тони Арнольд
18

Ответ на это дается непосредственно в документах 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) для всех модулей, CocoaPods, как правило, может воссоздать одну и ту же установку. (Технически нет никакой гарантии, что при запуске установки pod будут получены и воссозданы идентичные артефакты, когда не используется SHA коммитов в Podfile. Это особенно верно при использовании zip-файлов в Podfile.)

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

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

shah1988
источник
13

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

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

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

  1. Распространить ... Отправить в iOS App Store / Сохранить для предприятия или Специальное развертывание / что у вас есть

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

  3. Щелкните правой кнопкой мыши и сожмите «WhitherProject»

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

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

Алекс Науда
источник
23
Cocoapods специально рекомендует зарегистрироваться на сайте Podfile.lock: docs.cocoapods.org/guides/working_with_teams.html
cbowns
Интересно. Поскольку Podfile.lockзапекает пути к локальным модулям, я не рассматривал возможность добавления их в систему управления версиями. Однако теперь, когда я думаю об этом, он не отличается от локальных изменений, которые я делаю, Podfileно никогда не фиксирую. Спасибо за указание на это.
Алекс Науда
Изменилась ли ссылка для работы с командами? Ничего не говорится о Podfile.lockфайле.
ingh.am
4
@ ing0 Я думаю , что новая связь эта одна
фита
Преимущество проверки в Podfile.lock заключается в том, что очевидно, были ли обновлены какие-либо ваши модули или их зависимости.
Тим Поттер
11

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

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

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

xcuserdata/
nomann
источник
10

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

Я считаю себя поклонником добавления Pod в репозиторий по одной фундаментальной причине, которую никто, похоже, не замечает, что произойдет, если библиотека, от которой так зависит наш проект, внезапно будет удалена из Интернета?

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

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

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

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

leewilson86
источник
2
Это один из лучших ответов на вечный вопрос «Проверяю ли я свои зависимости в системе контроля версий». Во-первых, вы объясняете фактическое, основанное на риске, деловое обоснование для своих рассуждений. Во-вторых, вы напоминаете всем, что в конечном итоге лучшим решением будет то, что выполнит работу и заставит людей работать вместе. Вы удаляете религию из уравнения. Хорошая работа!
Брэндон
8

В конце концов, зависит от вашего подхода.

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

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

Лично я хотел бы, чтобы стручки из, так как node_modules , если бы я использовал узел или bower_components , если бы я использовал Бауэр . Это применимо практически к любому Dependency Manager, и это философия git submodules.

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

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

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

zevarito
источник
8

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

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

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

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

Якуб Трухларж
источник
2

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

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

Шон
источник
2

Проверьте в стручках.

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

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

Почему?

CocoaPods или любые другие внешние библиотеки могут измениться, что может сломать вещи. Либо они могут двигаться, либо переименовываться, либо удаляться вообще. Вы не можете полагаться на Интернет, чтобы хранить вещи для вас. Ваш ноутбук мог умереть, и есть критическая ошибка в производстве, которую необходимо исправить. Главный разработчик может быть сбит автобусом, и его замена должна начаться в спешке. И я бы хотел, чтобы последний был теоретическим примером, но на самом деле это произошло при стартапе, с которым я был. ПОКОЙСЯ С МИРОМ.

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

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

n13
источник
2

Плюсы не проверяя в 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, а затем запустить pod install.
  3. У вас должно быть подключение к Интернету pod install, и источник пакетов должен быть доступен.
  4. Если владелец зависимости удаляет свой пакет, у вас проблемы.

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

efthimio
источник
1

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

Matt
источник
1

TL; DR: когда вы отслеживаете Pods/папку, проект легче выбрать из. Когда вы не отслеживаете это, легче работать, когда вы работаете в команде.

Хотя организация Cocoapods поощряет нас отслеживать Pods/каталог, они говорят, что разработчикам решать, делать это или нет, основываясь на этих плюсах и минусах:  http://guides.cocoapods.org/using/using-cocoapods.html # должен-я-заезд в стручки-каталог-в-исток-контроль

Лично я обычно отслеживаю Pods/папку только для проектов, над которыми я больше не буду работать некоторое время. Таким образом, любой разработчик может быстро извлечь из него пользу и продолжить работу, используя подходящую версию cocoapods.

С другой стороны, я думаю, что история коммитов становится чище и проще объединять код и просматривать код другого человека, когда вы не отслеживаете Pods/папку. Обычно я устанавливаю версию библиотеки cocoapod при ее установке, чтобы каждый мог установить проект, используя те же версии, что и я.

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

Итог : когда вы отслеживаете Pods/папку, проект легче выбрать из. Когда вы не отслеживаете это, легче улучшить.

marcelosalloum
источник
0

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

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

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

jaredpetker
источник
0

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

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

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

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

  1. Репо-контроль источника будет меньше и займет меньше места. Пока доступны исходные коды (например, GitHub) для всех модулей, CocoaPods, как правило, может воссоздать одну и ту же установку. (Технически нет гарантии, что при запуске установки pod будут получены и воссозданы идентичные артефакты, если не использовать SHA для фиксации в Podfile. Это особенно верно при использовании zip-файлов в Podfile.)
  2. При выполнении операций контроля версий не будет никаких конфликтов, таких как объединение ветвей с различными версиями Pod. Независимо от того, проверяете ли вы в каталоге Pods, Podfile и Podfile.lock всегда должны находиться под контролем версий.
Сурабх Махна
источник
Вы можете использовать эту ссылку для любого сомнения: guides.cocoapods.org/using/…
Сурабх Махна