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

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

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

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

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

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


git git-submodules xcode4
person Simon Whitaker    schedule 09.01.2012    source источник
comment
Оформить заказ на cocoapods cocoapods.org   -  person Steve Moser    schedule 10.08.2012

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

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

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

person Community    schedule 09.01.2012
comment
Интересно, я не подумал предоставить рабочему пространству собственный репозиторий git. Что касается остальной части структуры, мне кажется более целесообразным сделать библиотеку подмодулем приложения, которое ее использует. Мне было бы интересно узнать больше о причинах создания репозиториев родственного уровня. - person Simon Whitaker; 09.01.2012
comment
В этом случае библиотека была разделена между приложением iOS и Mac, поэтому создание подмодуля каждого из них добавило бы сложности. - person ; 09.01.2012

arrow_upward
2
arrow_downward

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

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

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

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

git submodule add <path to repo>
git submodule update

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

person nickcharlton    schedule 09.01.2012
comment
Я бы запретил комментировать, что клиентская библиотека не меняется. Если кто-то видит их как отдельные компоненты и хочет отслеживать разные истории, ему определенно следует использовать подмодули, и точка. Я все еще +1 это :) - person Romain; 09.01.2012