Слияние файлов проекта 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. Определить общее «Исходное дерево» для вашего кода и второе для стороннейsources.

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

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

Answer 2

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

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

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

Answer 3

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

Теперь нажмите кнопку «слияния»!

Вот и все!

Answer 4

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

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

*.pbxproj -crlf -diff -merge

Answer 5

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