Я хочу добавить проект, который в этом случае создается в Netbeans, но этот вопрос является общим для большинства IDE. Это просто, что я должен включить в свой репозиторий. Например, Netbeans создает папку nbproject, eclipse создает папку .settings и т. Д. Если я включу их в свой репозиторий, каковы преимущества / недостатки включения или отсутствия включения определенных параметров проекта.
В данном случае это личный проект, поэтому я не думаю, что другие люди начнут работать над ним, но было бы неплохо добавить минимальный набор настроек проекта, чтобы самому проекту было легко начать работу на разных машинах.
programming-practices
git
project
maintainability
Даниэль Фигероа
источник
источник
Ответы:
Это действительно зависит от того, какие данные это и должно быть решено в каждом конкретном случае, возможно, даже для отдельных файлов. Посмотрите на содержимое этих файлов. Чаще всего вы можете сказать, что они имеют в виду. Такие вещи, как положение и размер окон IDE - это то, что вам не нужно в управлении исходным кодом.
Но некоторые файлы проекта IDE являются жизненно важными метаданными проекта. Я плохо знаю Netbeans, но для eclipse файл .project сообщает IDE, как называется проект, что это веб-проект Java и т. Д., А файл .classpath содержит информацию об исходных папках и библиотеках. Некоторые файлы в каталоге .settings могут быть одинаково важны, например, org.eclipse.core.resources.prefs содержит информацию о том, какая кодировка должна использоваться для каких файлов.
Как метаданные проекта, этот материал очень заслуживает того, чтобы быть версионным в системе контроля версий.
Некоторые IDE могут импортировать метаданные проекта из других IDE. Было бы еще лучше иметь его в форме, не привязанной к конкретной IDE.
Для Java есть такая вещь: Maven . Это накладывает строгие соглашения на структуру проекта и позволяет указывать метаданные проекта (например, зависимости библиотек) в одной точке (файл с именем pom.xml, который находится в главном каталоге проекта и, конечно, в управлении исходным кодом). Существуют плагины, которые затем создают файлы проекта IDE из конфигурации Maven, и другие, которые могут автоматизировать процесс сборки проекта или делать что угодно. Иногда кажется, что это делает вещи излишне сложными, и на то, чтобы учиться, требуется некоторое время, но выгоды, как правило, того стоят.
источник
Это действительно зависит от того, какую информацию вы хотели бы иметь в хранилище. Если вам нужно все, вплоть до того, какие файлы были открыты и редактировались во время фиксации, и вы единственный, кто использует репозиторий, продолжайте фиксировать все это, но знайте, что он может не работать на другом компьютере ,
Если вы хотите иметь возможность делиться своим кодом с другими людьми, которые могут не использовать ту же IDE, просто передайте сам код без какой-либо конкретной реализации проекта.
Если вы знаете, что все используют одну и ту же среду IDE, то, вероятно, вы можете включить в нее все, что не связано с конкретным компьютером, то есть файлы настроек / папки только для самой среды IDE, так что они уже могут иметь возможность импортировать проект как IDE ожидает этого.
источник
Артефакты , которые помогают развитию и бесполезны , к сборки / выпуска или сам проект должен не быть включен. Репозиторий должен быть чистым и аккуратным и содержать только те вещи, которые имеют отношение к проекту, а не к вашей среде . Репо должен быть в курсе ваших привычек. И во-вторых, это излишне будет беспокоить вас, когда вы делаете что-то похожее
git status... но эй, я никогда не делал никаких изменений ... аааа, игнорируйте это.Позвольте мне привести более практический пример (я буду использовать
gitздесь в качестве инструмента):Вы никогда не захотите, чтобы (рекурсивный) субмодуль в вашем основном репо содержал материал, специфичный для IDE (это может также повлиять на среду основного проекта), потому что все, что вас волнует, - это код, который был написан кем-то другим (или вами) и является использования внутри текущего проекта. Не среда, в которой он был разработан. Вы, вероятно, не хотите делать это с кем-то еще.
Чтобы иметь возможность использовать ваши настройки на другом компьютере, я предлагаю покопаться в вашей IDE и посмотреть, какую поддержку она оказывает для таких вещей. Emacs имеет
initи сервер Emacs тоже. Или вы можете сделать свой собственный макрос или скрипт (.sh), который выполняет настройку автоматически.источник
Если это личный проект, я скажу сохранить настройки в системе контроля версий. Лично ничто так не убивает мою мотивацию для проекта, как повторная настройка среды разработки.
Когда вовлечено больше людей, я не помещаю эти вещи в систему контроля версий. В моей команде мы используем смесь IntelliJ, Sublime Text и Eclipse. Файлы IDE просто добавляют беспорядок и приводят к фиксации коммитов этих файлов от других людей для IDE, которую вы не используете.
Кроме того, ваш проект не должен зависеть от IDE в любом случае. Сервер сборки не будет загружать Eclipse для компиляции вашего продукта, поэтому он уже должен быть без IDE. Более незначительный момент: это устраняет личную организацию в рамках проекта. Например, в IntelliJ мне нравится использовать много модулей в нашем проекте. Никто другой, использующий IntelliJ, не беспокоится об этом, потому что мы не храним файлы .iml (модуль).
Если ваша команда использует ту же IDE, то это лучше, но тогда кто-то фиксирует неверную запись .classpath, потому что он использовал абсолютный путь. Теперь все, кто использует IDE, беспокоятся об этом.
Конечно, недостатком является то, что есть больше настроек, когда кто-то проверяет проект. Я думаю, это того стоит. Мы используем Ivy для управления зависимостями и располагаем информацией о настройках, зависимостях и т. Д. Несмотря на эти первоначальные затраты, я думаю, что стоит оставить настройки IDE вне контроля источников.
источник