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

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

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

EDIT - Некоторые связанные вопросы:

Git и pbxproj

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

РЕСУРСЫ:

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

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

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/

Ответ 1

Разбейте свои проекты на более мелкие, более логичные библиотеки/пакеты. Массивные проекты регулярно являются признаком плохого дизайна, например, объект, который слишком много или слишком велик.
Дизайн для легкой перестройки - это также помогает, если вы пишете программы, которые должны быть построены с помощью нескольких инструментов или IDE. Многие из моих "проектов" можно реконструировать, добавив один каталог.
Удалить посторонние фазы сборки. Пример: я удалил фазу сборки "Копировать заголовки" из всех проектов. Явно включайте конкретные файлы с помощью директивы include.
Используйте файлы xcconfig везде, где это возможно. Это также уменьшает количество изменений, которые вы должны внести при обновлении ваших сборок. Файлы xcconfig определяют набор параметров сборки и поддерживают #include. Конечно, вы затем удаляете (большинство) пользовательских настроек из каждого проекта и цели при определении xcconfig для использования.
Для целевых зависимостей: создайте цели, которые выполняют логические операции, а не физические операции. Обычно это цель сценария оболочки или совокупная цель. Например: "построить зависимости", "запустить все модульные тесты", "собрать все", "очистить все". тогда вам не нужно поддерживать каждое изменение зависимостей на каждом этапе пути - это как использование ссылок.
Определите общее "Исходное дерево" для вашего кода и второе для сторонних источников.
Доступны внешние инструменты сборки. Это может быть вариант для вас (по крайней мере, для некоторых из ваших целей).

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

Ответ 2

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

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

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

Ответ 3

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

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

*.pbxproj -crlf -diff -merge

Ответ 4

Чтобы сравнить два проекта Xcode, откройте Open FileMerge (откройте xcode и выберите Xcode (из панели man) → Откройте инструменты разработчика → FileMerge). теперь нажмите кнопку "влево" и откройте основную директорию проекта xcode. нажмите кнопку "Вправо" и откройте основной каталог проекта xcode для сравнения.

Теперь нажмите кнопку "Слияние"!

Вот оно!

Ответ 5

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