Они все полезны, если вы хотите, чтобы в вашей команде были единые настройки.
.classpath и .project означают, что каждый может начать работу с проектом, просто импортировав его. Любые изменения в библиотеках и исходных файлах, включенных в проект, будут отмечены всеми, когда они будут зарегистрированы.
В каталоге .settings есть такие вещи, как параметры форматирования кода и то, что компилятор считает предупреждениями, ошибками или ОК. Для согласованности я также начал проверять их (если, конечно, каждый в вашей команде может согласиться со стандартом форматирования).
Я обнаружил, что самое большое ограничение в совместном использовании элементов управления версиями в Eclipse - это определения библиотек. Кажется, что определения библиотек хранятся только для каждого пользователя, поэтому, если вы ссылаетесь на «библиотеку» в файле .classpath, каждый другой пользователь должен вручную определить содержимое этой библиотеки (или вручную импортировать экспортированный файл определений библиотеки). .
<Ч />
Редактировать: (Обращаясь к комментарию @ mliebelt ниже)
Вы можете фиксировать файлы .settings только в том случае, если вы пытаетесь поддерживать согласованность / стандартизацию между разработчиками. Если это не проблема для проекта, то не стоит беспокоиться о сохранении файлов .settings. Файлы, которые являются специфическими для любимых плагинов человека, вероятно, также не должны быть зафиксированы (хотя я не думаю, что это повредит, если бы они были, вероятно, будут проигнорированы?).
Два наиболее распространенных из них, которые я нашел заслуживающими внимания, это org.eclipse.jdt.core.prefs и org.eclipse.jdt.ui.prefs, которые являются основными для любого (Java) проекта Eclipse.