По моему опыту, за исключением тех редких случаев, когда задействованы чисто локальные настройки, все должно находиться в системе контроля версий. Закон управления версиями гласит, что все, что было предложено, должно работать теми, кто отказывается. К сожалению, eclipse часто вызывает такие вещи .classpath:
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>
Итак, на моем Mac это работает, и, возможно, у кого-то на Mac есть такая же JRE, но это не сработает ни для кого.
Кроме того, нет простого способа обойти это. Eclipse всегда будет добавлять это. Я ХОЧУ, чтобы там был файл .classpath, потому что в нашей папке lib есть несколько сторонних JAR-файлов, в которых мы заботимся о версиях, поэтому мы оставляем их там, чтобы новым разработчикам не приходилось их получать. . Мы переходим к управляемой системе, но по-прежнему зарегистрированы управляемые + неуправляемые зависимости. Это означает, что всем разработчикам просто нужно убедиться, что в их каталогах есть два каталога .classpath. Но это лучше, чем исправлять JRE каждый раз, когда вы извлекаете и меняете свой .classpath каждый раз, когда вы фиксируете.
Зато Eclipse делает для вас и другие приятные вещи. Файл .project обычно будет одинаковым для всех экземпляров, поэтому включите его. Но самое лучшее в системе управления версиями для eclipse - это настройки Run Configurations. На вкладке «Общие» в диалоговом окне «Конфигурации запуска» сохраните конфигурации, чтобы они отображались для ваших коллег в списках избранного для отладки и запуска. Для меня .launchв .settingsкаталог помещается куча файлов , поэтому мы все можем их использовать.
Итак, я говорю: .settingsкаталог переходит в систему контроля версий для конфигураций запуска (кроме * .prefs)
.classpath остается вне
.project идет в.
