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

Question

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

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

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

Answer 1

В конце концов, вам решать, какой подход вы выберете.

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

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

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

Однако иногда вы можете быть действительно уверены в состоянии state-of-art определенной зависимости, таким образом, вы сами несете зависимость внутри вашего проекта.Конечно, есть несколько недостатков, которые применимы, если вы делаете это, но проблемы относятся не только к Cocoapods, но и к любому Менеджеру зависимостей.

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

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

Answer 2

Лично это зависит:

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

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

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

Answer 3

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

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

Answer 4

Проверка в модулях.

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

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

Почему?

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

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

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

Answer 5

Плюсы не проверка 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, который облегчает недостатки.

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

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

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

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