Что я могу увидеть в проекте Git/Mercurial в проекте Eclipse. Metadata?

Ответ 1

Файлы, о которых я лично знаю:

• version.ini(не очень интересно)
• .plugins/org.eclipse.jdt.core/variablesAndContainers.dat(переменные pathpath)
• .plugins/org.eclipse.core.resources/.projects/*/. location (проекты в рабочей области)

Где-то у меня есть рабочее пространство Eclipse, используемое для тестирования некоторых связанных с Eclipse инструментов, которые довольно сильно сокращены, но работает. Я посмотрю, смогу ли я его выкопать.

Ответ 2

GitHub поддерживает проект сообщества "gitignore", который каталогизирует предложенные файлы спецификаций для игнорирования для различных платформ, редакторов и языков: https://github.com/github/gitignore p >

Eclipse игнорируется здесь: https://github.com/github/gitignore/blob/master/Global/Eclipse.gitignore

(Если есть другие файлы, о которых они должны знать, сообщите им об этом!)

Ответ 3

Метаданные и рабочее пространство

Я бы никогда не обменивался папкой .metadata. Фактически, если у вас нет определенной причины, я бы даже не разделил папку рабочего пространства, но вместо этого разделил каждый проект отдельно с помощью git. Таким образом, папка .metadata всегда будет находиться в родительской папке вашего репозитория git, и вам не нужно думать о том, нужно ли вообще ее игнорировать:

|-- workspace/
|  \-- .metadata/
|  |-- yourProjectOne/
|  |  \-- .git/
|  |  |-- .project
|  |  |-- src/
|  |  |-- ...
|  |-- yourProjectTwo/
|  |  \-- .git/
|  |  |-- .project/
|  |  |-- src/
|  |  |-- ...

Конкретный проект

Вероятно, вы всегда должны делиться файлами .project и никогда .settings/. .classpath может зависеть от вашей среды, но я бы также не предложил поделиться ею, потому что это может вызвать конфликты (например, если один пользователь использует openjdk, а другой использует sun-jdk. .settings содержит настройки и настройки для eclipse и многое изменится, поэтому он не должен быть общим. Если вы правильно импортируете проект после клонирования его из git, то у вас также не будет проблем.

В документации eclipse указано следующее о файле .project:

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

и

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

Я также предлагаю использовать Maven, так как это сэкономит вам массу проблем с управлением зависимостями и .classpath

Maven

Основное отличие проекта Maven заключается в том, что вы можете импортировать проект как Maven → "Существующие проекты Maven" и, следовательно, нужно только делиться файлами pom.xml и .project в git. Затем Eclipse автоматически создаст файлы .classpath, .settings/. Таким образом, очевидно, вам не нужно делиться ими. Если что-то изменится в pom.xml, вы просто запустите Maven → "Обновить конфигурацию проекта" и Maven → "Обновить зависимости".

Без Maven

Вы должны делиться файлом .project, а не папкой .settings/. Вы можете согласиться на использование .classpath, но это может привести к конфликтам, как описано выше. Я бы посоветовал не делиться им. Для импорта проекта используйте следующий метод:

После того, как вы клонировали репозиторий git, вы можете просто использовать "Импорт" - "Существующий проект из рабочей области". eclipse будет чтить файл .project, но воссоздает файлы .classpath и .settings/. После импорта вам нужно будет настроить путь к классам вручную из Eclipse (и каждый раз ваша команда хочет использовать другую библиотеку).

Если вы не делитесь файлом .project, тогда невозможно импортировать проект с помощью Eclipse. Сначала вам нужно будет создать новый проект с помощью мастера проекта, а затем вы можете выбрать импорт "General- > File System", это скопирует все файлы в ваше рабочее пространство. Это, вероятно, не то, что вы хотите, потому что это означает, что вы не можете клонировать репозиторий git в рабочую область, вы должны клонировать его где-то в другом месте, а затем импортировать из него. Поэтому вы всегда должны делиться файлом .project.

Пожалуйста, оставьте оценку, если у вас есть предложения по этому объяснению или если вы не согласны с этим. Я надеюсь, что это поможет тому или иному.

Ответ 4

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

Ответ 5

Я постоянно сохраняю .project и .classpath, они не только безопасны для git, но и полезны.

.class и .settings находятся в моем gitignore. Они генерируются и соответствуют конкретным лицам.