Лучшие практики для Xcode + Git для проектов с несколькими разработчиками

Я могу создать репо и использовать GitHub/BitBucket для моих собственных проектов. У меня были проблемы при работе с другими разработчиками или попытка развернуть проект на GitHub.

Мне известны другие ответы, такие как Рекомендации по репозиториям git в проектах с открытым исходным кодом, но есть проблемы с OSX/Xcode, которые я хочу знать, как решить.

  • .DS_Store файлы могут быть болью. Вы можете использовать .gitignore, но что произойдет, если они уже были включены, или другой разработчик добавляет их обратно через неуклюжую команду git?

  • .xcodeproj будет иметь изменения в именах каталогов и профилях разработчиков для другого человека. Какой лучший способ выполнить слияние или избежать конфликтов?

  • Если я разветкил или вытащил из проекта github, как я могу очистить эти проблемы, а также минимизировать конфликты слияния для сопровождающего?

Если у людей есть пример .gitignore, созданный для Xcode, или скрипты, которые они используют для инициализации своих репозиториев, это было бы здорово!

ОТВЕТЫ

Ответ 1

Я попробую один за другим:

я. Вам нужно использовать git filter-branch, только если вам нужно полностью удалить файлы из своей истории. Если эти файлы не содержат информации о кредитной карте, я думаю, что должно быть достаточно:

git rm --cached .DS_Store
git commit -m "{Your message}"

затем добавьте этот файл в .gitignore и зафиксируйте его.

Это приведет к удалению файла из репозитория, но сохранит файл в рабочем каталоге. Если вы нажмете его, а затем кто-то еще потянет это сообщение, он может удалить свой файл, поэтому вы ДОЛЖНЫ сообщить об этом. Зафиксировав .gitignore, вы снова запретите другим разработчикам добавлять этот файл. Если вы не являетесь сопровождающим, то я не думаю, что вы должны что-то делать, но обратитесь к этой проблеме для сопровождающего.

II. Я твердо убежден, что скрытые файлы любой природы в большинстве случаев не должны помещаться в хранилище именно по этой причине. Поэтому я думаю, что вы должны сделать то же самое с .xcodeproj как с .DS_Store и поместить его в .gitignore и зафиксировать. .gitignore является исключением для правила выше.

III. Если эти файлы будут правильно проигнорированы, то в будущем с ними не будет никаких проблем. Если они уже находятся в репо, и кто-то хочет сделать такую ​​очистку, это должно быть сделано сторонником и сообщено внутри команды.

Надеюсь, что это поможет!

Ответ 2

  • Поместите .DS_Store в .gitignore. Затем, если вы еще этого не сделали, добавьте .gitignore в репо. (Вы не должны игнорировать .gitignore.) Теперь все разработчики будут игнорировать файлы .DS_Store. Если какие-либо ошибки были добавлены в репо ошибочно, прежде чем вы поместите .DS_Store в .gitignore, теперь вы можете удалить их (в фиксации), и они должны оставаться в стороне.

  • xcodeproj - это каталог. Единственным файлом в этом каталоге, который должен находиться в репозитории, является файл project.pbxproj. Я вообще игнорирую всех остальных, помещая эти строки в мой .gitignore:

    *.xcuserstate
project.xcworkspace/
xcuserdata/

    Вам следует избегать установки абсолютных путей в настройках сборки. Используйте относительные пути.

    В ваших сборках отладки и выпуска следует использовать iPhone Developer как идентификатор подписи кода, так что Xcode автоматически выберет локальный профиль разработчика. Если вы хотите создать IPA (для распространения), Xcode предложит переписать его с другим идентификатором, после чего вы сможете выбрать свой профиль распространения, если вам нужно.

  • Если вы пытаетесь использовать проект из github, который допустил эти ошибки, вы можете попытаться заставить сопровождающего его исправить или вы можете не прикасаться к файлам .DS_Store и идентификаторы подписи кода в тех же самых записях, что вы хотите отправить вверх по течению.

Ответ 3

git ветвь фильтра может помочь вам удалить ненужные файлы (файлы .DS_Store) из вашего репозитория - см., например, https://help.github.com/articles/remove-sensitive-data

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

Ответ 4

Для второго вопроса, касающегося конфликтов .xcodeproj и слияния.

Используя файл .gitattributes, чтобы указать, что конфликты слияния для всех файлов .pbxproj должны обрабатываться с использованием стратегии merge=union, что должно означать, что Git знает, чтобы объединиться в изменениях с обеих сторон конфликта, сначала беря изменения вверх по течению.

Эта статья объясняет это немного подробнее

Ответ 5

Вы правы в том смысле, что если добавлен .DS_Store, .gitignore не будет иметь большой поддержки, но я думаю, что это все еще хороший ресурс для вас и других.

Когда я запускаю проект, я обычно смотрю на этот список, чтобы увидеть, есть ли уже существующий .gitignore. Более конкретно для вас this является Objective-C .gitignore.

Мы надеемся, что эти ресурсы будут полезны.

Ответ 6

В качестве пользователя Mac вы должны скачать инструмент, например SourceTree, который поддерживает Git Поток. Git Поток поможет вам установить некоторые рекомендации по поводу того, как ваши коллабораторы будут выполнять код для репо и, по крайней мере, сделать конфликты слияния менее частыми и более управляемыми. Для набора файлов gitignore для разных типов проектов вы можете перейти на GitHub и загрузить тот, который готов к работе. Для Xcode они перечислены как Objective-C.gitignore. Это хорошее стартовое место, и оно даже охватывает Cocoapods. Если вы используете внешние библиотеки, ваш проект должен использовать CocoaPods, чтобы вы могли изолировать этот код и сохранить его вне своего репо и избегать подмодулей Git.

Теперь, когда вы обнаружите, что файл сделал это в вашем репо, как .DS_Store, просто удалите его и перейдите. Убедитесь, что вы добавили его в файл .gitignore, который был отмечен в проекте.

Как и для xcodeproj... не должно быть такой настройки в файле, который является специфичным для пользователя, поскольку указанные выше фильтры gitignore. Если схема должна быть общей, убедитесь, что вы проверили общий доступ в разделе "Схемы управления", и вы проверите файлы в этом подкаталоге. Вы должны использовать автоматический выбор сертификатов, поэтому единственным реальным выбором является Developer или Distribution. Вы также должны использовать переменные предусмотренные в Xcode, которые избегают полных путей жесткого кодирования. При попытке вспомнить пример Plists пришел на ум, в этом случае вы могли бы написать /Users/me/MyProject/Resources/MyProject.plist, но вместо этого следует использовать $(SRCROOT)/resources/MyProject.plist.