Работно пространство на 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