Должен ли я добавить рабочую область в систему контроля версий при работе с Eclipse?
Я единственный разработчик в этом проекте.
6 ответов
Я бы не добавил всю рабочую область, но я бы добавил .classpath а также .project файлы (а также источник, конечно), так что вы можете восстановить проект, если это необходимо.
Я бы не стал выделять все рабочее пространство. Но стоит экспортировать настройки платформы и проверить их в системе контроля версий (возможно, в отдельном проекте SCM, поскольку они на самом деле не принадлежат какому-либо отдельному проекту), если вы внесли несколько изменений в случае необходимости импортировать их в новое рабочее пространство.,
Примерами этих файлов являются настройки для:
- Java-> Стиль кода-> Форматер
- Java-> Стиль кода-> Очистить
- Java-> Стиль кода-> Шаблоны кода
- Общие-> Редакторы-Текстовые редакторы-Правописание-Словарь
- Любые другие настройки, в которые вы внесли значительные изменения в поддержку импорта / экспорта.
Вы должны проверить в первоисточниках / ресурсах для проекта. Как уже отмечалось, для типичного проекта это файлы.project и.classpath.
В зависимости от типа проекта я бы добавил папку.settings из проекта. Эта папка содержит параметры проекта, которые переопределяют настройки платформы, а также другие параметры проекта. Если они необходимы для вашего проекта, я бы добавил их.
Нет.
Файлы, сгенерированные IDE или процессом сборки (двоичные файлы, документация, сгенерированная генератором), не должны проверяться в системе контроля версий. Единственные файлы, которые должны быть проверены, - это ваши исходные файлы и внешние библиотеки, которые используются вашими исходными файлами.
Вам также могут быть интересны ответы на этот вопрос: что НЕ должно находиться под контролем источников?
Я хотел бы зафиксировать только те проекты, над которыми вы работаете, а также файлы.classpath и.project, а не само рабочее пространство.
Даже если вы единственный разработчик, избегайте фиксации каталога.settings. Вы можете переключиться на другую версию Eclipse или другую установку с другим набором плагинов, и когда вы извлекаете проекты во второй установке, каталог.settings будет другим. Также каталог.metadata должен меняться.
Тем не менее, попытайтесь использовать Maven так, чтобы файлы Eclipse .project и.classpath могли быть сгенерированы без необходимости их регистрации.
Я поиграл с идеей (с Subversion), что у меня есть папка "MyProject_Eclipseproj", которая содержит только файлы и каталоги проекта Eclipse, с подпоркой svn:externals, которая вытягивает все файлы / каталоги "MyProject".
Итак, макет будет:
/repos/trunk/MyProject
/repos/trunk/MyProject/build.xml
/repos/trunk/MyProject/src
/repos/trunk/MyProject/src/com
/repos/trunk/MyProject/src/com/mypackage
/repos/trunk/MyProject/src/com/mypackage/MyClass.java
/repos/trunk/MyProject_Eclipse_34 <- external prop goes here
/repos/trunk/MyProject_Eclipse_34/.settings/
/repos/trunk/MyProject_Eclipse_34/.project
/repos/trunk/MyProject_Eclipse_34/.classpath
/repos/trunk/MyProject_Eclipse_35 <- external prop goes here
/repos/trunk/MyProject_Eclipse_35/.settings/
/repos/trunk/MyProject_Eclipse_35/.project
/repos/trunk/MyProject_Eclipse_35/.classpath
Папка MyProject была бы чистым кодом, без загрязнения затмения. MyProject_Eclipse_Ver будет содержать специфичные для Eclipse файлы и указатели для извлечения папок с кодом. Вы также можете иметь отдельные папки для разных версий Eclipse, чтобы каждый разработчик не был вынужден обновляться, если что-то изменилось в файле.settings или.project между версиями.