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