Опишите свой рабочий процесс использования управления версиями (VCS или DVCS) [закрытый]

Основная особенность, которую используют все VCS для различных задач, о которых вы говорите, - это ветвление : способность изолировать усилия по разработке совместным способом. Поскольку это центральная система контроля версий, несколько разработчиков могут сотрудничать в одной ветке с пессимистическими или оптимистичными блокировками файлов, чтобы создать параллельную историю.

Но наличие VCS имеет два основных воздействия на ветвление:

1. Оно имеет тенденцию препятствовать фиксации, потому что после фиксации файла он немедленно повлияет на рабочую область других представлений с такой же конфигурацией (т.е. ветвь").
   ~ Процесс "публикации" является активным, с немедленными последствиями,
   ~ в то время как "потребляющая" часть (обновление вашей рабочей области) является пассивной (вы вынужден иметь дело с изменениями, опубликованными другими сразу после обновления вашего рабочего пространства)
2. Он хорошо работает для линейного рабочего процесса слияния (т.е. в обоих направлениях »- от A к B к A к B ...).Слияние тривиально, все модификации из A просто переносятся в B

Теперь:

Реализация функции

Любая VCS сделает это, создав ветвь, но что меня сильно удивило, так это то, что «функция» ветка не проста:
* функция может стать слишком сложной
* она может быть готова к следующему выпуску
* только некоторые его часть, возможно, потребуется снова объединить с основной веткой разработки
* это может зависеть от других функций, которые еще не полностью реализованы

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

Исправление ошибок

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

Проверка кода

Лучше всего использовать с внешними инструментами (, например, Crucible ) и широко использует функции VCS, такие как обвинение или аннотации, чтобы лучше назначать исправления кода после проверки.

Рефакторинг кода (post code-review)

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

Включить исправления

Тот же комментарий, что и в последнем пункте.Если патч большой, нужно создать ветку.

Выпуск более новой версии вашего приложения

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

• остановку того, что в настоящее время выполняется;
• копирование новых файлов
• их развертывание (обновление базы данных sql, веб-приложение, ...)
• создание экземпляров всех файлов конфигурации (с правильными значениями, адресами, номером порта, путями, ...)
• перезапуск (и если ваша система состоит из нескольких компонентов, перезапускать их в правильном порядке!)

Ключевыми моментами с VCS и управлением выпусками являются:

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

Механизм выпуска также влияет на двоичные зависимости:

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

Вы также можете выбрать зависимости от исходного кода (и получить все исходники других внутренних проектов, которые вам нужны для вашего собственного), и VCS хорошо адаптирована для этого, но не всегда возможно / практично перекомпилировать все.