Подтвердить что ты не робот

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

Мне интересно, имеет ли параметр merge = union в .gitattributes смысл для файлов .pbxproj.

Позиция manpage для этой опции:

Запустите трехстороннее выравнивание уровня файла для текстовых файлов, но возьмите строки из обеих версий, вместо того, чтобы оставлять маркеры конфликта. Это имеет тенденцию оставлять добавленные строки в результирующем файле в случайном порядке, и пользователь должен проверить результат.

Как правило, это должно быть хорошо для 90% случаев добавления файлов в проект. У кого-нибудь есть опыт с этим?

4b9b3361

Ответ 1

Не прямой опыт, но:

Файл pbxproj на самом деле не сменен человеку.
Хотя это простой текст ASCII, это форма JSON. По сути, вы хотите рассматривать его как двоичный файл.

(следовательно, gitignore решение)

Собственно, Peter Hosey добавляет в комментарий:

Это список свойств, а не JSON. Те же идеи, различный синтаксис.

Истина заключается в том, что более опасно отказываться от слияния этого файла .pbxproj, чем это полезно.
Файл .pbxproj - это просто JSON (аналогично XML). Из опыта, как раз о единственном конфликте слияния, который вы когда-либо получали, есть, если два человека добавили файлы одновременно. Решение в 99% случаев конфликта слияния состоит в том, чтобы сохранить обе стороны слияния.

Итак, объединение "union" (с директивой gitattributes merge) имеет смысл, но сделайте некоторое испытание, чтобы увидеть, делает ли оно то же самое, что и script, упомянутых в последнем вопросе.

Ответ 2

В последнее время я работаю с большой командой и пробовал *.pbxproj merge=union, но в конечном итоге пришлось удалить его.

Проблема заключалась в том, что скобки становились неуместными на регулярной основе, что делало файлы нечитаемыми. Это правда, что он работает большую часть времени - но не может быть 1 из 4 раза.

Мы вернемся к использованию *.pbxproj -crlf -merge. Это, пожалуй, лучшее решение для нас.