Следует ли фиксировать файлы, измененные Eclipse?

Вообще говоря, вы должны регистрировать (и фиксировать после изменений) все, что вносит вклад в сборку, И не может быть повторно сгенерирован путем полной перестройки И зависит от рабочей станции. (Последствия этого утверждения зависят от вашего процесса / процедуры сборки, которая предназначена.)

Это означает, что вы должны исключить все, что повторно создается при полной сборке и т. Д., Чтобы это не регистрировалось (и не предлагалось для регистрации).

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

Но в некоторых случаях все немного туманно. Например, файл .classpath может быть основным источником пути сборки Eclipse; например если у вас есть файлы JAR в дереве проекта, а не с помощью Maven. (С Maven плагин m2eclipse генерирует файл .classpath из информации о зависимостях в файле POM, и, следовательно, этот файл не следует возвращать.)

Кроме того, некоторые аспекты являются пограничными. Например, в проектах с JSP и Javascripts я обнаружил, что важно изменить свойства фасета, чтобы отключить неработающие валидаторы. И есть хороший повод рассматривать эти изменения как часть проекта, а не как личные предпочтения.

Отделение групповых / проектных предпочтений от личных предпочтений - одна из областей, в которой (IMO) Eclipse серьезно не хватает.

Эти файлы лучше не фиксировать, так как пути / настройки могут отличаться на разных рабочих станциях.

Вы можете использовать какой-нибудь инструмент для сборки, чтобы преодолеть это. (например, Maven)

Как будто кто-то из членов команды не использует eclipse (используя какой-то другой ide), эти файлы не имеют для них значения.

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

РЕДАКТИРОВАТЬ:

Больше объяснений;

Я работал в группах, в которых люди использовали NetBeans, Eclipse, IDEA ... в течение очень долгого времени, и на самом деле это не вариант для них менять среду IDE. Это повлияет только на продуктивность этого человека.

Когда люди привыкают к своим IDE, они изучают сокращения, они знают, где искать некоторые функции (рефакторинг / генерация установщика getter / реализация переопределения требуемых методов ....), поэтому, если вы заставите их использовать какую-то другую IDE, они просто сделают вещи труднее для них и медленнее для всего процесса. ИМХО, и по моему опыту всегда хорошо иметь гибкую кодовую базу. Я любитель Eclipse и, вероятно, не хотел бы работать с какой-либо другой IDE, так как я знаю множество сокращений, которые делают работу быстрее / проще для меня, и эти сокращения различаются в разных IDE.

Все файлы IDE могут быть автоматически восстановлены самой IDE, вероятно, всего за пару кликов.

И в моем текущем проекте есть 3 разработчика, каждый из которых без проблем использует разные IDE eclipse (я), NetBeans, IDEA. Я не хочу видеть файлы конфигурации IDEA или NetBeans, которые не имеют смысла для eclipse, когда я проверяю источник из репо. То же и для них.

Да, но убедитесь, что пути в рабочей области относительны, а не абсолютны. Наличие этих файлов в рабочей области позволяет членам вашей команды работать в той же среде, что и вы. Это также значительно упрощает настройку новой среды разработки: вы просто извлекаете ее из системы управления версиями, а в Eclipse используйте «Импорт ...> Существующие проекты в рабочую область».

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

Я работаю в проекте, где мы фиксируем файл .classpath, так как очень полезно, чтобы все разработчики использовали один и тот же :) Если вы используете зависимости только внутри своей рабочей области, этот файл использует относительные пути и, следовательно, должен быть одинаковым на всех машинах. Даже если этот файл может не понадобиться для сборки (например, с помощью ant), его очень удобно синхронизировать.

Напротив, org.eclipse.core.prefs хранит (afaik) специфические для проекта, но личные предпочтения разработчиков, которые я бы не стал проверять.

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

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

Эти файлы могут быть очень полезны для обмена конфигурациями между разработчиками. Альтернативой является либо использование Maven (что является огромной задачей для уже существующего проекта), либо постоянно устаревшие пошаговые инструкции, а новым разработчикам требуется полдня, пока они даже не смогут собрать проект.

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

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

Их игнорирование также делает ваш проект чище, что мне всегда нравилось.

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