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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

файл .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 здесь .

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

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

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

Я нахожусь в лагере разработчиков, которые не проверяют библиотеки, полагая, что у нас есть хорошая копия в другом месте. Итак, в моем .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-сервер или процесс архивации, как я описал выше.

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

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

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

xcuserdata/

Я должен сказать, что я фанат отправки 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.

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

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

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

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

Лично я хотел бы, чтобы стручки из, так как 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 когда-либо исчезнет, ​​или источник одного из модулей выйдет из строя, вам совершенно не повезет, если вы попытаетесь построить заново из архива.

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

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

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

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

Почему?

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

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

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

Плюсы не проверяя в 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облегчения минусов.

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

TL; DR: когда вы отслеживаете 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

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

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

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