Как вы обрабатываете отдельные файлы разработчика под контролем версий?

Question

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

Как вы справляетесь с этим?

Answer 1

Наши файлы свойств находятся в каталоге "properties". Каждый разработчик имеет свои собственные файлы «username.properties», которые они могут переопределять в свойствах файлов, относящихся к среде, таких как «dev.properties» или «test.properties». Это использует преимущества неизменных свойств ANT (включая личные, затем свойства среды).

Answer 2

Сохраните набор настроек по умолчанию в управлении источником, а затем либо:

• у каждого разработчика есть дополнительный набор конфигов, которыми они управляют сами (например, не хранятся в системе контроля версий) или

• пусть каждый разработчик хранит свои собственные настройки в управлении исходным кодом в соответствии с какой-то схемой идентификации (username.properties, которую использует @Dustin)

Преимущество сохранения определенных настроек разработчика в управлении исходным кодом облегчает миграцию с одного компьютера на другой (например, в случае аппаратного сбоя или обновления). Это простой svn co [repos] и ant

Answer 3

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

С уважением

Answer 4

Мы создаем или используем приложение с помощью ant, и наши файлы сборки ant имеют ссылку на имя файла, подобное этому:

$ {env.COMPUTERNAME} -. Properties

Все свойства в этом файле переопределят свойства в основном файле сборки, если они существуют. Таким образом, разработчики могут создать файл переопределения, названный по имени их компьютера, чтобы переопределить любое из свойств, которое им нравится, например, имя базы данных и / или URL-адрес jdbc. Затем этот файл можно проверить в системе контроля версий

Answer 5

Используйте SVN: игнорировать (или его эквивалент), чтобы убедиться, что они не проверены в вашей внешней ветви.

Answer 6

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

Answer 7

Используйте шаблоны, вы не добавляете db-config к управлению исходным кодом (на самом деле вы используете SVN: IGNORE для него), а добавляете db-config.tmpl или db-config.template или db-config.tmp или что-то еще это ясно говорит вам, что это шаблон.

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

Answer 8

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

У нас есть файл personal.properties, который загружается и переопределяет любые значения проекта по умолчанию. Файл находится в домашнем каталоге пользователя. Для любых значений, специфичных для пользователя, значение по умолчанию устанавливается следующим образом:

database_user_name = DATABASE_USER_NAME_MUST_BE_SET_IN_PERSONAL_PROPERTIES_FILE

Файл никогда не редактируется разработчиком, поэтому никакая информация о пользователе не проверяется в системе контроля версий, и если разработчик забывает установить значение в файле personal.properties, вы получаете очевидную ошибку, такую ​​как:

Unable to login to database with username: "DATABASE_USER_NAME_MUST_BE_SET_IN_PERSONAL_PROPERTIES_FILE"

Answer 9

Это было своего рода ответ в предыдущем посте. Хотя вопрос был больше направлен на WebApps, реальная проблема - это именно то, с чем вы сталкиваетесь сейчас.

Как вы поддерживаете Java-приложения в различных промежуточных средах?

Answer 10

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

Или иметь отдельный репозиторий для пользовательских файлов.

Или оставьте это на усмотрение отдельного разработчика в том, что он делает со своими файлами.