Я занимаюсь разработкой iOS уже пару месяцев и узнал о многообещающей библиотеке CocoaPods для управления зависимостями.
Я попробовал это в личном проекте: добавила зависимость от Kiwi к моему подфайлу, запустила pod install CocoaPodsTest.xcodeproj
и voila, он отлично поработал.
Единственное, что мне не интересно, это: что я регистрирую, и что я игнорирую для контроля версий? Кажется очевидным, что я хочу проверить сам Podfile и, возможно, файл .xcworkspace; но я игнорирую каталог Pods/? Существуют ли другие файлы, которые будут сгенерированы по дороге (когда я добавлю другие зависимости), которые я также должен добавить в свой .gitignore?
Лично я не проверяю каталог и содержимое Pods. Я не могу сказать, что я долгое время рассматривал последствия, но мои рассуждения - это что-то вроде:
Подфайл ссылается на конкретный тег или или на фиксацию каждой зависимости, поэтому сами Pod могут быть сгенерированы из podfile, и они более похожи на продукт промежуточной сборки, чем источник, и, следовательно, не нуждаются в управлении версиями в мой проект.
Я фиксирую каталог Pods. Я не согласен с тем, что каталог Pods является артефактом сборки. На самом деле я бы сказал, что это определенно не так. Это часть вашего источника приложения: он не будет строить без него!
Легче думать о CocoaPods как инструменте разработчика, а не о инструменте построения. Он не создает ваш проект, он просто клонирует и устанавливает ваши зависимости для вас. Не нужно устанавливать CocoaPods, чтобы иметь возможность просто создавать ваш проект.
Из-за того, что CocoaPods зависит от вашей сборки, теперь вам нужно убедиться, что она доступна везде, где вам может понадобиться для создания вашего проекта... администратору этой команды это нужно, вашему CI-серверу это нужно. Вы, как правило, всегда сможете клонировать исходный репозиторий и строить без каких-либо дополнительных усилий.
Не фиксируя каталог Pods, вы также создаете массированную головную боль, если вы часто переключаете ветки. Теперь вам нужно запустить pod install каждый раз, когда вы переключаете ветки, чтобы убедиться, что ваши зависимости верны. Это может быть меньше хлопот, так как ваши зависимости стабилизируются, но в начале проекта это массивное время.
Итак, что я игнорирую? Ничего. Подфайл, файл блокировки и каталог Pods все передаются. Поверьте мне, это сэкономит вам много хлопот. Каковы минусы? Немного больше репо? Не конец света.
Я рекомендую использовать GitHubs Objective-C gitignore. В частности, лучшие практики:
Podfile
должен всегда находиться под контролем источника.Podfile.lock
должен всегда находиться под контролем источника.:path
должна находиться под контролем источника../Pods
может находиться под контролем источника.Для получения дополнительной информации вы можете обратиться к официальному руководству .
source: Im является членом основной команды CocoaPods, например @alloy
Хотя папка Pods является артефактом сборки, есть причины, которые вы можете учесть, решив, чтобы сохранить ее под контролем источника:
:head
и :git
в настоящее время не используют коммиты, хранящиеся в Podfile.lock
).Я вообще работаю над приложениями клиентов. В этом случае я также добавляю каталог Pods в репо, чтобы гарантировать, что в любой момент времени любой разработчик сможет выполнить проверку и построить и запустить.
Если бы это было наше приложение, я бы, вероятно, исключил каталог Pods, пока я не буду работать над ним некоторое время.
На самом деле, я должен заключить, что я, возможно, не лучший человек, чтобы ответить на ваш вопрос, в сравнении с мнениями о чистых пользователях:) Не стесняйтесь читать этот вопрос от https://twitter.com/CocoaPodsOrg.
Нет ответа на самом деле предлагает .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 здесь.
Я проверяю все. (Pods/
и Podfile.lock
.)
Я хочу иметь возможность клонировать репозиторий и знать, что все будет работать так же, как в прошлый раз, когда я использовал приложение.
Я предпочел бы продавать вещи, кроме риска иметь разные результаты, которые могут быть вызваны другой версией драгоценного камня, или кто-то переписывает историю в репозитории Pod и т.д.
Ответ на это дан непосредственно в документах 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 всегда должен находиться под контролем версий.
Я в лагере разработчиков, которые не проверяют библиотеки, предполагая, что у нас есть хорошая копия, доступная в другом месте. Итак, в моем .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-сервер или архивный процесс, как описано выше.
Podfile.lock
: docs.cocoapods.org/guides/working_with_teams.html
Podfile.lock
запекает пути к локальным модулям, я не рассматривал возможность добавления его в систему управления версиями. Однако, теперь, когда я думаю об этом, он не отличается от локальных изменений, которые я делаю в Podfile
но никогда не Podfile
. Спасибо за указание на это.
Я предпочитаю использовать Pods
каталог вместе с Podfile
и Podfile.lock
, чтобы убедиться, что кто-то из моей команды может проверить источник в любое время, и им не нужно ни о чем беспокоиться, либо делать дополнительные вещи, чтобы заставить его работать.
Это также помогает в сценарии, в котором вы исправили ошибку внутри одного из модулей или изменили какое-либо поведение в соответствии с вашими потребностями, но эти изменения не будут доступны на других компьютерах, если они не были зафиксированы.
И игнорировать ненужные каталоги:
xcuserdata/
Я должен сказать, что я поклонник фиксации Pods в репозитории. Следуя упомянутой ссылке, вы получите хороший .gitignore файл, чтобы получить ваши проекты Xcode для iOS, чтобы разрешить Pods, но также и для вас, чтобы вы легко их исключили, если хотите: https://github.com/github/gitignore/blob/master/Objective-C.gitignore
Мое рассуждение о том, чтобы быть поклонником добавления Pods в репозиторий, является одной из основополагающих причин, по которым никто, кажется, не набирает обороты, что происходит, если библиотека, в которой наш проект так зависит, внезапно удаляется из Интернета?
NB... обратите внимание, что ветвь "master" для разработки - это только примеры, очевидно, "ведущие" ветки в системах управления версиями, должны быть очищены и разворачиваться/создаваться в любое время
Я думаю, что эти снимки в ваших репозиториях кода, безусловно, лучше, чем строгий размер репозитория. Как уже упоминалось, файл podfile.lock - в то время как контролируемая версия даст вам хорошую историю ваших версий Pod.
В конце дня, если у вас есть срочный срок, жесткий бюджет, время имеет сущность - нам нужно быть максимально находчивыми и не тратить время на строгие идеологии, а вместо этого использовать набор инструментов работать вместе - сделать нашу жизнь более эффективной.
В конце вам подходит подход, который вы делаете.
Это то, о чем думает команда Cocoapods:
Независимо от того, просматриваете ли вы свою папку "Под", зависит от вас, так как рабочие процессы варьируются от проекта к проекту. Мы рекомендуем сохранить Pods под контролем источника и не добавляйте его в свой .gitignore. Но в конечном итоге это решение зависит от вас.
Лично я хотел бы оставить Pods в качестве node_modules, если бы я использовал Node или bower_components, если бы использовал Bower. Это применимо практически для любого менеджера зависимостей, а также является основой подмодулей git.
Однако иногда бывает, что вы можете быть действительно уверены в состоянии определенной зависимости, таким образом вы несете свою зависимость в своем проекте. Конечно, есть несколько недостатков, которые применяются, если вы это делаете, но проблемы относятся не только к Cocoapods, но и к любому диспетчеру зависимостей.
Ниже приведен хороший список про/против, сделанный командой Cocoapods, и полный текст цитаты, упомянутой ранее.
Команда Cocoapods: следует ли проверять каталог Pods в исходном элементе управления?
Это зависит, лично:
pods.xcodeproj
являются частью элемента управления. Это означает, например, если у вас есть проект в swift 4
, но некоторые стручки должны быть в swift 3.2
потому что они еще не обновлены, эти настройки будут сохранены. В противном случае тот, кто клонировал репо, закончил бы ошибками.pod install
, противоположное не может быть сделано.Некоторые минусы: большой репозиторий, путающие различия (в основном для членов команды), потенциально больше конфликтов.
Зайдите в Pods.
Я думаю, что это должен быть принцип разработки программного обеспечения
Почему?
CocoaPods или любые другие внешние библиотеки могут измениться, что может нарушить работу. Или они могут перемещаться или переименовываться или вообще удаляться. Вы не можете полагаться на интернет, чтобы хранить вещи для вас. Ваш ноутбук, возможно, умер, и есть критическая ошибка в производстве, которая должна быть исправлена. Главный разработчик может попасть в автобус, и его замена должна начать спешить. И я желаю, чтобы последний был теоретическим примером, но это действительно произошло при запуске, с которым я был. RIP.
Теперь, реалистично, вы не можете проверить все зависимости. Вы не можете проверить изображение машины, которую вы использовали для создания сборок; вы не можете проверить точную версию компилятора. И так далее. Существуют реальные пределы. Но проверьте все, что вы можете - не делая этого, просто делает вашу жизнь труднее. И мы этого не хотим.
Заключительное слово: Pods не создают артефакты. Построить артефакты - это то, что генерируется из ваших сборников. Ваша сборка использует Pods, а не создает их. Я даже не знаю, почему это нужно обсуждать.
Для меня наибольшая проблема заключается в том, что будущий корректив вашего источника. Если вы планируете продлить свой проект на какое-то время, а CocoaPods когда-либо уйдет, или источник одного из пакетов упадет, вам не повезло, если вы попытаетесь построить свежие из архива.
Это можно было бы смягчить с помощью периодических полных архивов источников.
Плюсы не проверки в Pods/
для контроля версий (в субъективном порядке важности):
pod install
может заблокировать изменения.Podfile
и 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. На практике это не всегда будет работать. Многие контейнеры значительно превышают ограничение на размер файлов github, поэтому, если вы используете github, у вас будет проблема проверки в каталоге Pods.
Независимо от того, просматриваете ли вы свою папку "Подписки", зависит от вас, так как рабочие процессы варьируются от проекта к проекту. Мы рекомендуем хранить каталог Pods под контролем источника и не добавлять его в свой .gitignore. Но в конечном итоге это решение зависит от вас:
Преимущества проверки в каталоге Pods
Преимущества игнорирования каталога Pods
Похоже, что хороший способ структурирования действительно состоит в том, чтобы иметь каталог "Pods" в качестве подмодуля/отдельного проекта git, вот почему.
Наличие в вашем проекте репо, когда вы работаете с несколькими разработчиками, может привести к тому, что ОЧЕНЬ БОЛЬШОЙ разницы в запросах на тяну, где практически невозможно увидеть фактическую работу, которая была изменена людьми (думаю, несколько сотен или тысяч файлов изменены для библиотек и только несколько изменений в самом проекте).
Я вижу проблему не совершать ничего с git, так как человек, владеющий библиотекой, может снять его в любое время, и вы, по сути, SOL, это также решает.
Podfile
(где мы используемgit add -a
), что мы должныgitignore
каталог Podfile.lock & Pod?