Слияние файлов проекта XCode

Question

Часто встречаются конфликты в файле проекта Xcode (Project.xcodeproj/project.pbxproj) при объединении веток (я использую git). Иногда это легко, но иногда я получаю поврежденный файл проекта и должен вернуться. В худшем случае я должен исправить файл проекта вручную во втором коммите (который может быть сжат с предыдущим) путем перетаскивания файлов и т. Д.

У кого-нибудь есть советы, как обрабатывать конфликты слияния в больших и сложных файлах, таких как файл проекта Xcode?

---

РЕДАКТИРОВАТЬ-- Некоторые связанные вопросы:

Git и pbxproj

Должен ли я объединить файлы.pbxproj с git, используя merge=union?

РЕСУРСЫ:

http://www.alphaworks.ibm.com/tech/xmldiffmerge

http://www2.informatik.hu-berlin.de/~obecker/XSLT/

http://tdm.berlios.de/3dm/doc/thesis.pdf

http://www.cs.hut.fi/~ctl/3dm/

http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/

Answer 1

1. Разбейте свои проекты на более мелкие, более логичные библиотеки / пакеты. Массовые проекты регулярно являются признаком плохого дизайна, например, объект, который слишком много или слишком велик.

2. Дизайн для легкой перестройки - это также помогает, если вы пишете программы, которые должны быть собраны с помощью нескольких инструментов или IDE. Многие из моих "проектов" можно восстановить, добавив один каталог.

3. Удалить посторонние фазы сборки. Пример: я удалил фазу сборки "Копировать заголовки" из всех проектов. Явно включайте конкретные файлы через директиву include.

4. Используйте файлы xcconfig везде, где это возможно. Это также уменьшает количество изменений, которые необходимо внести при обновлении ваших сборок. Файлы xcconfig определяют набор настроек сборки и поддержку #include, Конечно, вы затем удаляете (большинство) определенных пользователем настроек из каждого проекта и цели при определении xcconfig для использования.

5. Для целевых зависимостей: создайте цели, которые выполняют логические операции, а не физические операции. Обычно это цель сценария оболочки или совокупная цель. Например: "построить зависимости", "запустить все модульные тесты", "собрать все", "очистить все". тогда вам не нужно поддерживать каждое изменение зависимости на каждом этапе пути - это все равно что использовать ссылки.

6. Определите общее "Исходное дерево" для вашего кода и второе для сторонних источников.

7. Доступны внешние инструменты сборки. Это может быть вариант для вас (по крайней мере, для некоторых из ваших целей).

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

Answer 2

Вы можете попробовать https://github.com/simonwagner/mergepbx/

Это скрипт, который поможет вам правильно объединить файлы проекта XCode. Обратите внимание, что это все еще альфа.

Отказ от ответственности: я являюсь автором mergepbx.

Answer 3

Для сравнения двух проектов XCode откройте FileMerge (откройте XCode и выберите XCode (на панели manu) -> Открыть инструменты разработчика -> FileMerge). Теперь нажмите кнопку "влево" и откройте главный каталог проекта xcode. нажмите кнопку "вправо" и откройте основной каталог проекта xcode для сравнения.

Теперь нажмите кнопку "объединить"!

Это оно!

Answer 4

Лучший способ, который я нашел, - дать Git команду обрабатывать файл.pbxproj как двоичный файл. Это предотвращает грязные слияния.

Добавьте это в ваш файл.gitatributes:

*.pbxproj -crlf -diff -merge

Answer 5

Рассмотрим еще один вариант, который может помочь уменьшить количество раз, когда вы испытываете проблему. Для объяснения я позвоню в ветку, в которой ветки членов команды происходят из ветки "разработка". В вашей команде есть соглашение, что при изменении файла проекта изменения (наряду с любыми другими изменениями, необходимыми для обеспечения целостности сборки) фиксируются в отдельном коммите. Этот коммит затем вставляется в ветку разработки. Другие члены команды, которые планируют изменить файл проекта в своей ветке, могут либо выбрать вишню в свою ветку, либо переназначить свою ветку на последней разработке. Такой подход требует общения в команде и некоторой дисциплины. Как я уже сказал, это не всегда возможно; в некоторых проектах это может помочь, а в некоторых - нет.