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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

---

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

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

Answer 4

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

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

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

Answer 5

.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 здесь .

Answer 6

Ответ на этот вопрос дан прямо в документации 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 всегда должны находиться под контролем версий.

Answer 7

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

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

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

Answer 8

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

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

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

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

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

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

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

Answer 9

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

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

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

xcuserdata/

Answer 10

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

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

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

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

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

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