Лучшая структура git и Xcode для развивающихся вариантов одного и того же продукта
В Best Practice есть аналогичный вопрос для управления вариантами проектов в Git? но контекст другой, и я подозреваю, что ответ может быть слишком.
У меня есть Какао-продукт "Первый", управляемый с помощью Xcode и версионированный с помощью git. "Первый" все еще развивается, и в настоящее время находится в его третьей версии.
Затем приходит клиент и просит вариант First, называемый Second. Изменения с Первого на Второе влияют на многие, но не на все файлы. Изменения влияют на исходный код, но также и ресурсы (графические элементы, файлы пера, списки свойств...).
Теперь эти два продукта живы и имеют несколько общих файлов. Однако некоторые изменения, такие как исправление ошибок, могут относиться к обоим продуктам. Возможно, новая функция может быть добавлена к обоим продуктам.
Что было бы лучшим способом управлять таким сценарием:
- с Xcode
- с мерзавцем
У меня есть две идеи, которые являются взаимоисключающими:
Идея 1: перевести ветку "Первый" во "Второй" и применить любое применимое изменение от одного проекта к другому. Это приводит к двум совершенно отдельным каталогам и проектам Xcode.
Идея 2: Добавить цель с именем "Второй" в проект Xcode. Теперь один и тот же проект XCode имеет две цели и используется для разработки и создания обоих продуктов. Но это затрудняет управление релизами для First и Second в git (у релизов нет причин для синхронизации).
Идея 2 делает процесс параллельной разработки очень простым. Код всегда синхронизирован. Расхождения могут быть обработаны через переменные времени компиляции и один исходный файл ИЛИ через разные исходные файлы. Это делает управление версиями более неясным.
Идея 1, возможно, чище, но какова лучшая практика управления тем, что остается общим для двух проектов? Можете ли вы сделать "частичное слияние" между двумя ветками Git? На каком основании? Или это должно быть обработано вручную?
Может быть возможно инкапсулировать и извлечь некоторую общую часть в модуль или библиотеку, но не всегда. Например, я не думаю, что это возможно для обычных значков документов. Кроме того, рефакторинг "First", чтобы все обычные элементы были извлечены в сборочном виде, является важным делом, которое я предпочел бы выполнять постепенно.
Я понимаю, что не может быть идеального решения. Я ищу идеи и предложения. Как относительно недавний пользователь git, я также понимаю, что это может быть вопрос RTFM. Тогда просто укажите мне FM к R.
Большое спасибо.
1 ответ
Мое предпочтение - идея2. В настоящее время я делаю это как способ написания плагина для Основного приложения, а затем клиентских приложений, которые работают на всех узлах кластера. Подключаемый модуль и клиенты совместно используют 90% одного и того же кода, поэтому это очень упрощает поддержку и отладку информации о том, что и как происходит.