Я занимаюсь разработкой iOS уже несколько месяцев и только что узнал о многообещающей библиотеке CocoaPods для управления зависимостями.
Я опробовал его в личном проекте: добавил зависимость от Kiwi в мой Podfile, запустил pod install CocoaPodsTest.xcodeproj
и вуаля , он отлично работал.
Единственное, что меня интересует: что мне регистрировать и что игнорировать для контроля версий? Кажется очевидным, что я хочу проверить сам файл Podfile и, возможно, файл .xcworkspace; но я игнорирую каталог Pods /? Есть ли другие файлы, которые будут сгенерированы в будущем (когда я добавлю другие зависимости), которые я также должен добавить в свой .gitignore?
источник
Podfile.lock
: Cocoapods выдает его как рекомендованное для контроля версий.Я фиксирую свой каталог Pods. Я не согласен с тем, что каталог Pods является артефактом сборки. На самом деле я бы сказал, что определенно нет. Это часть исходного кода вашего приложения: без него он не будет построен!
Про CocoPods проще думать как инструмент для разработчиков, а не как инструмент для сборки. Он не создает ваш проект, он просто клонирует и устанавливает ваши зависимости для вас. Не нужно устанавливать CocoaPods, чтобы можно было просто построить свой проект.
Делая CocoaPods зависимым от вашей сборки, теперь вам нужно убедиться, что он доступен везде, где вам может понадобиться построить ваш проект ... это нужно администратору команды, это нужно вашему CI-серверу. Как правило, вы всегда должны иметь возможность клонировать исходный репозиторий и создавать его без каких-либо дополнительных усилий.
Отсутствие фиксации вашего каталога Pods также создает сильную головную боль, если вы часто переключаете ветви. Теперь вам нужно запускать pod install каждый раз, когда вы переключаете ветки, чтобы убедиться, что ваши зависимости верны. Это может быть меньше хлопот, так как ваши зависимости стабилизируются, но на ранних стадиях проекта это огромная трата времени.
Итак, что я игнорирую? Ничего. Podfile, файл блокировки и каталог Pods - все фиксируется. Поверьте мне, это избавит вас от многих хлопот. Какие минусы? Немного больше репо? Не конец света.
источник
Pods
каталог, это вызовет у вас боль, так как его регистрация также сопряжена с рядом проблем. Например, разработчик изменяет версию зависимости в,Podfile
не забывая проверять обновленные источники в Pods. Закон Мэрфи.pod install
каждый раз, когда вы переключаете ветку, вы тратите драгоценные ... десятки секунд - но это полностью устраняет этот класс проблем.It won't build without it!
С таким же успехом вы могли бы совершить XCodeЯ рекомендую использовать GitHub's Objective-C gitignore . Подробно, лучшие практики:
Podfile
Должен всегда находиться под контролем источника.Podfile.lock
Должен всегда находиться под контролем источника.:path
опция, должен находиться под контролем исходного кода../Pods
Папка может находиться под контролем источника.Для получения дополнительной информации вы можете обратиться к официальному руководству .
источник: я являюсь членом основной команды CocoaPods, как @alloy
Хотя папка Pods является артефактом сборки, есть причины, по которым вы могли бы подумать, решая, стоит ли держать ее под контролем исходного кода:
:head
и в:git
настоящее время не используют коммиты, хранящиеся вPodfile.lock
).источник
файл .gitignore
Нет ответа на самом деле предлагает
.gitignore
, так что вот два вкуса.Проверка в каталоге Pods ( Преимущества )
Git игнорирует Xcode / iOS, пропуская системные файлы Mac OS, Xcode, сборки, другие репозитории и резервные копии.
.gitignore:
Игнорирование каталога Pods ( Преимущества )
.gitignore: (добавить в предыдущий список)
Если
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 "
источник
Я нахожусь в лагере разработчиков, которые не проверяют библиотеки, полагая, что у нас есть хорошая копия в другом месте. Итак, в моем .gitignore я включаю следующие строки, специфичные для CocoaPods:
Затем я удостоверяюсь, что у нас есть копия библиотек в безопасном месте. Вместо того, чтобы (неправильно) использовать репозиторий кода проекта для хранения зависимостей (скомпилированных или нет), я думаю, что лучший способ сделать это - архивировать сборки. Если вы используете CI-сервер для своих сборок (например, Jenkins), вы можете постоянно архивировать любые сборки, которые важны для вас. Если вы делаете все свои производственные сборки в своем локальном XCode, возьмите в привычку брать архив своего проекта для любых сборок, которые вам нужно сохранить. Примерно так: 1. Продукт -> Архив
Распространить ... Отправить в iOS App Store / Сохранить для предприятия или Специальное развертывание / что у вас есть
Раскройте папку вашего проекта в Finder
Щелкните правой кнопкой мыши и сожмите «WhitherProject»
Это обеспечивает встроенный образ всего проекта, включая полные настройки проекта и рабочей области, используемые для построения приложения, а также двоичные дистрибутивы (такие как Sparkle, проприетарные SDK, такие как TestFlight и т. Д.), Независимо от того, используют ли они CocoaPods или нет.
Обновление: я передумал по этому поводу, и теперь передаю управление
Podfile.lock
исходным кодом. Тем не менее, я все еще считаю, что сами модули являются артефактами сборки и должны управляться как таковые вне контроля источника, с помощью другого метода, такого как ваш CI-сервер или процесс архивации, как я описал выше.источник
Podfile.lock
: docs.cocoapods.org/guides/working_with_teams.htmlPodfile.lock
запекает пути к локальным модулям, я не рассматривал возможность добавления их в систему управления версиями. Однако теперь, когда я думаю об этом, он не отличается от локальных изменений, которые я делаю,Podfile
но никогда не фиксирую. Спасибо за указание на это.Podfile.lock
файле.Я предпочитаю совершать
Pods
каталог вместе сPodfile
и ,Podfile.lock
чтобы убедиться , что кто -то в моей команде может кассу источника в любое время , и они не должны беспокоиться о чем - нибудь или сделать дополнительный материал , чтобы сделать его работу.Это также помогает в сценарии, в котором вы исправили ошибку внутри одного из модулей или изменили поведение в соответствии с вашими потребностями, но эти изменения не будут доступны на других компьютерах, если они не зафиксированы.
И игнорировать ненужные каталоги:
источник
Я должен сказать, что я фанат отправки Pods в хранилище. Перейдя по уже упоминавшейся ссылке, вы получите хороший файл .gitignore, чтобы получить доступ к своим проектам Xcode для iOS, чтобы разрешить Pods, а также, если хотите, легко исключить их: https://github.com/github/gitignore/ блоб / ведущий / Objective-C.gitignore
Я считаю себя поклонником добавления Pod в репозиторий по одной фундаментальной причине, которую никто, похоже, не замечает, что произойдет, если библиотека, от которой так зависит наш проект, внезапно будет удалена из Интернета?
NB ... пожалуйста, обратите внимание, что ветвь 'master' для разработки приведена только для примера, очевидно, что ветки 'master' в системах контроля версий должны быть чистыми и развертываемыми / встраиваемыми в любое время
Я думаю, что снимки в ваших репозиториях кода, безусловно, лучше, чем строгие размеры репозитория. И, как уже упоминалось, файл podfile.lock, контролируемый версией, даст вам хорошую историю ваших версий Pod.
В конце дня, если у вас срочные сроки, жесткий бюджет, время имеет первостепенное значение - мы должны быть настолько изобретательны, насколько это возможно, и не тратить время на строгие идеологии, а вместо этого использовать набор инструментов для совместной работы. - сделать нашу жизнь проще и эффективнее.
источник
В конце концов, зависит от вашего подхода.
Вот что думает команда Cocoapods:
Лично я хотел бы, чтобы стручки из, так как node_modules , если бы я использовал узел или bower_components , если бы я использовал Бауэр . Это применимо практически к любому Dependency Manager, и это философия git submodules.
Однако иногда вы можете быть действительно уверены в состоянии определенной зависимости, так как вы сами несете зависимость в своем проекте. Конечно, есть несколько недостатков, которые применимы, если вы делаете это, но проблемы относятся не только к Cocoapods, но и к любому Dependency Manager.
Ниже приведен хороший список плюсов и минусов, составленный командой Cocoapods, и полный текст цитаты, упомянутый ранее.
Команда Cocoapods: Должен ли я проверить каталог Pods в систему контроля версий?
источник
Это зависит, лично:
Почему стручки должны быть частью репо (под контролем источника) и не должны игнорироваться
pods.xcodeproj
Настройки также являются частью системы контроля версий. Это означает, например, что если у вас есть проектswift 4
, но некоторые модули должны быть включены,swift 3.2
потому что они еще не обновлены, эти настройки будут сохранены. В противном случае тот, кто клонировал репо, в итоге получит ошибки.pod install
, обратное не может быть сделано.Некоторые минусы: большой репозиторий, запутанные различия (в основном для членов команды), потенциально больше конфликтов.
источник
Для меня самая большая проблема - это проверка вашего источника на будущее. Если вы планируете, чтобы ваш проект длился какое-то время, а CocoaPods когда-либо исчезнет, или источник одного из модулей выйдет из строя, вам совершенно не повезет, если вы попытаетесь построить заново из архива.
Это может быть смягчено периодическими архивами с полным исходным кодом.
источник
Проверьте в стручках.
Я думаю, что это должен быть принцип разработки программного обеспечения
Почему?
CocoaPods или любые другие внешние библиотеки могут измениться, что может сломать вещи. Либо они могут двигаться, либо переименовываться, либо удаляться вообще. Вы не можете полагаться на Интернет, чтобы хранить вещи для вас. Ваш ноутбук мог умереть, и есть критическая ошибка в производстве, которую необходимо исправить. Главный разработчик может быть сбит автобусом, и его замена должна начаться в спешке. И я бы хотел, чтобы последний был теоретическим примером, но на самом деле это произошло при стартапе, с которым я был. ПОКОЙСЯ С МИРОМ.
Теперь, на самом деле, вы не можете действительно проверить ВСЕ зависимости. Вы не можете проверить изображение машины, которую использовали для создания сборок; Вы не можете проверить точную версию компилятора. И так далее. Есть реалистичные пределы. Но отметьте все, что можете - если вы не сделаете этого, ваша жизнь станет еще сложнее. И мы этого не хотим.
Последнее слово: стручки не являются артефактами сборки. Артефакты сборки - это то, что генерируется из ваших сборок. Ваша сборка использует Pod, а не генерирует их. Я даже не уверен, почему это должно обсуждаться.
источник
Плюсы не проверяя в
Pods/
контроля версий (в субъективном порядке важности):pod install
может перекрыть изменения.Podfile
иPods/
каталогом обнаруживаются быстрее среди товарищей по команде. Если вы зарегистрируетесьPods/
и, например, обновите версию вPodfile
, но забудете запуститьpod install
или зарегистрировать измененияPods/
, вам будет гораздо сложнее заметить источник расхождений. ЕслиPods/
не зарегистрирован, вам всегда нужно бежать вpod install
любом случае.JAR
файлы.venv/
(виртуальные среды) иnode_modules/
никогда не включаются в контроль версий. Если бы мы были полностью агностиком о вопросе, не проверяя вPods
будет по умолчанию на основе прецедента.Минусы не проверка в
Pods/
pod install
при переключении веток или отмене коммитов.pod install
.pod install
, и источник пакетов должен быть доступен.Таким образом, не включая в
Pods
каталоге является ограждением против более плохой практики. В том числе вPods
каталоге делает запуск проекта проще. Я предпочитаю первое, а не второе. Вам не нужно будет опрашивать каждого нового человека в проекте о том, «что не следует делать», если нет возможности совершить определенные ошибки в первую очередь. Мне также нравится идея иметь отдельный контроль версий дляPods
облегчения минусов.источник
Теоретически, вы должны проверить в каталоге Pods. На практике это не всегда будет работать. Многие pods значительно превышают лимит размера файлов github, поэтому если вы используете github, у вас будут проблемы с проверкой в каталоге Pods.
источник
Хотя организация Cocoapods поощряет нас отслеживать
Pods/
каталог, они говорят, что разработчикам решать, делать это или нет, основываясь на этих плюсах и минусах: http://guides.cocoapods.org/using/using-cocoapods.html # должен-я-заезд в стручки-каталог-в-исток-контрольЛично я обычно отслеживаю
Pods/
папку только для проектов, над которыми я больше не буду работать некоторое время. Таким образом, любой разработчик может быстро извлечь из него пользу и продолжить работу, используя подходящую версию cocoapods.С другой стороны, я думаю, что история коммитов становится чище и проще объединять код и просматривать код другого человека, когда вы не отслеживаете
Pods/
папку. Обычно я устанавливаю версию библиотеки cocoapod при ее установке, чтобы каждый мог установить проект, используя те же версии, что и я.Также, когда
Pods/
каталог отслеживается, все разработчики должны использовать одну и ту же версию Cocoapods, чтобы предотвратить изменение десятков файлов каждый раз, когда мы запускаемpod install
для добавления / удаления модуля.Итог : когда вы отслеживаете
Pods/
папку, проект легче выбрать из. Когда вы не отслеживаете это, легче улучшить.источник
Похоже, что хороший способ структурировать это действительно было бы иметь каталог «Pods» в качестве подмодуля / отдельного проекта git, вот почему.
Наличие пакетов в репозитории проекта при работе с несколькими разработчиками может привести к ОЧЕНЬ БОЛЬШИМ различиям в запросах на получение, где практически невозможно увидеть реальную работу, которая была изменена людьми (например, от нескольких сотен до тысяч файлов были изменены для библиотек, и только мало что изменилось в реальном проекте).
Я вижу проблему не совершать что-либо для мерзавца, так как человек, владеющий библиотекой, может снять ее в любое время, и вы по сути SOL, это также решает эту проблему.
источник
Независимо от того, проверяете ли вы в своей папке Pods, зависит от вас, так как рабочие процессы варьируются от проекта к проекту. Мы рекомендуем держать каталог Pods под контролем исходного кода и не добавлять его в свой .gitignore. Но в конечном итоге это решение остается за вами:
Преимущества проверки в каталоге Pods
Преимущества игнорирования каталога Pods
источник