7

Приложение разработано с использованием Sencha Architect, в котором используется множество вспомогательных файлов для управления различными объектами, связанными с IDE (пути экспорта, управление версиями IDE и т. Д.).Как управлять файлами IDE в репозитории git?

Некоторые из этих файлов будут меняться каждый раз, когда член команды просто откроет проект в IDE Sencha Architect IDE.

Чтобы привести пример особенно неприятного изменения, рассмотрите свойство exportPath в файлах *.xds, созданных архитектором. У меня будет выбор сервера, который я публикую, по определенному пути, а другие члены команды будут иметь разные конфигурации сервера/пути.

В нашей кодовой базе, я бы очень хотел, чтобы либо иметь IDE файлы:

  1. в отдельном хранилище,
  2. в суб-модуль (да, ГИТ-специфический, я знаю,) или
  3. находятся на пользовательской машине, и VCS не замечает изменений в них.

Главное, что следует отметить, что Sencha Architect ожидает, что файлы находятся в определенных местах по сравнению с проектами, поэтому файлы IDE должны быть доступны в том же месте, что и обычные исходные файлы.

Кроме того, использование .gitignore не является вариантом, так как Sencha Architect напишет информацию в некоторых из них, которые жизненно важны для других членов команды, которые правильно их открывают. Например. при открытии проекта Sencha Architect мог бы решить модернизировать проект до более новой версии (ее необязательно, если вы хотите вообще открыть проект), и в ходе обновления среда IDE изменит часть исходного кода, файлы кода. Другие участники команды должны знать об обновлении версии, чтобы иметь возможность правильно открыть проект.

This SO question дает некоторый фон запутанному формату, который использует Sencha. Я прошу прощения за негативный тон в оценке архитектуры Sencha Architect, но кажется, что они взяли хорошую идею (с использованием метаданных и генерации кода) слишком далеко (недействительность использования всех хороших инструментов unix, включая git).

Какой будет предпочтительный подход здесь? И почему?

+0

Это зависит от того, насколько важны для проекта файлы. Например, в случае C# и ReSharper файлы DOTSettings помещаются в VCS, а файлы .user.DotSettings - нет. Задайте себе вопрос: если файл отсутствует, можно ли построить проект? Будет ли он правильно строить? – Athari

+0

@Athari: спасибо за ваш комментарий, я уточнил вопрос с дополнительной информацией, относящейся к этому – Steen

+0

Я боюсь, что нет простого решения, если параметры уровня проекта и уровня пользователя смешиваются в одном файле. Вы не можете зафиксировать только некоторые части файла и оставить другие игнорируемые AFAIK. Я отправил запрос функции Sencha для разделения опций в разные файлы. В то же время вы можете согласиться с другими разработчиками передавать файлы IDE только в случае существенных изменений и иметь дело с параметрами слияния. – Athari

ответ

6

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

Вы можете использовать ignore those files используя Git. В частности, файлы IDE являются хорошими кандидатами для глобального gitignore, поскольку каждый пользователь будет использовать любые IDE, которые они хотят, и эти настройки должны применяться ко всем их репозиториям.

+2

Я полностью согласен с вами. Однако в этом проекте уже есть все типы IDE-файлов под контролем версий, члены команды полагаются на файлы, находящиеся в VCS. Gitignoring их не вариант, так как Sencha Architect напишет информацию в некоторых из них, которые жизненно важны для других членов команды, которые правильно их открывают. Я добавлю это к вопросу. Благодарю. – Steen

0

Возможно, было полезно использовать управление версиями для файлов IDE, кроме файлов, в которых хранятся пользовательские настройки. См. Также https://intellij-support.jetbrains.com/entries/23393067.

Преимущество использования управления версиями для этих файлов

  • Совместное использование стилей кода для всей команды разработчиков
  • управлять и обмениваться вложенными репозиториев, которые находятся под контролем версий, а также.
  • и т.д.
+0

Ваша ссылка не работает, текущая рабочая ссылка https://intellij-support.jetbrains.com/hc/en-us/articles/206544839-How-to-manage-projects-under-Version-Control-Systems – azhidkov

Смежные вопросы