Рабочая область Xcode 4 с двумя взаимозависимыми проектами: я должен также использовать подмодуль git?

Question

Я работаю над приложением для iOS и разбил кодовую базу на два отдельных проекта: клиентская библиотека для веб-службы и проект приложения, который зависит от клиентской библиотеки.

Оба проекта были добавлены в одно рабочее пространство XCode с соответствующим образом объявленной зависимостью.

Каждый проект имеет свой собственный репозиторий git.В настоящее время два проекта извлечены из двух отдельных каталогов, и я управляю двумя репозиториями git независимо друг от друга.Единственное место, где в настоящее время определяется зависимость между этими двумя частями кода, находится в проекте Xcode приложения.

Однако мне интересно, следует ли мне добавлять репозиторий git клиентской библиотеки в виде подмодуля git хранилища приложения.Концептуально это кажется правильным, но я раньше не использовал подмодули git, и мне интересно, есть ли какие-то ошибки с использованием этого подхода с XCode?

(Я могу найти множество постов в блоге о том, как использовать рабочие пространства Xcode для управления межпроектными зависимостями, как это, и в другом месте множество документации по подмодулям git, но я не могу найти ни одной учетной записи проверенногои проверенный рабочий процесс для использования обоих вместе. Если вы знаете один, пожалуйста, опубликуйте ссылку!)

Answer 1

Использование подмодулей имеет смысл для того, что вы делаете. Особенно, если клиентская библиотека не сильно изменится.

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

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

Из корня основного проекта:

git submodule add <path to repo>
git submodule update

Должно быть все, что вам нужно.

Answer 2

Я принимал участие в проектах, которые делали это раньше, все с использованием следующего макета:

 * app-workspace
  * App.workspace
  * library [submodule]
   * Library.xcodeproj
   * library sources
  * app [submodule]
   * App.xcodeproj
   * app sources

Итак, рабочая область знает о проектах и ​​схемах сборки. Git-репозиторий рабочей области знает о подмодулях, содержащих проекты.

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

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

Место, где у вас могут возникнуть проблемы с взаимодействием с XCode, - это определение ваших схем сборки. Подход, который я недавно использовал, заключается в том, чтобы использовать редактор схем, чтобы определить схемы, которые я хочу использовать, как общие (вместо отдельных пользователей) и определенные в рабочей области на верхнем уровне, а не в проектах в подмодулях. , После того, как это сделано, и те определения схемы, переданные в git, отключите автоматическую генерацию схемы. Теперь все ваши разработчики и система CI согласны с тем, как создать ваш продукт.