Что проект Eclipse.метаданные можно ли безопасно игнорировать в Git / Mercurial?

У нас есть код для приложения Eclipse RCP в рабочей области Eclipse, содержащей несколько проектов Java. Мы используем Mercurial с простым .hgignore just *.класс (но та же проблема будет относиться к Git).

даже небольшое изменение кода может привести ко многим файлам .метаданные меняются.

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

тут кто-нибудь знает, что мы можем исключить? В качестве альтернативы, как мы можем воссоздать его, если мы вытащим код на новый компьютер?

36
eclipse git java mercurial rcp

5 ответов

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

  • версия.Ини (не очень интересно)
  • .Плагины/орг.затмение.JDT, предназначенным.core / variablesAndContainers.dat (переменные пути к классам)
  • .Плагины/орг.затмение.ядро.ресурсы./проекты./*/расположение (проекты в рабочей области)

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

15

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

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

(Если есть другие спецификации, что они должны знать, пусть они знают!)

51

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

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

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

Конкретные

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

в документация eclipse говорится о :

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

и:

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

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

Maven

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

Без Maven

вы должны поделиться и не . Вы можете рассматривать поделиться .classpath, но это может привести к конфликтам, как описано выше. Я бы тоже предложил не делиться. Используйте метод ниже для импорта проекта:

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

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

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

29

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

4

Я обычно держу .проект и. classpath, они не только безопасны для git, но и полезны.

.класс и. настройки находятся в моем gitignore. Они генерируются и person specific соответственно.

4