Лучшие практики для контроля версий с несколькими проектами

Question

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

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

В результате мы на самом деле не используем систему VC, что ОЧЕНЬ плохо, мы все знаем ... так что, предложения?

Answer 1

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

Почему это?
Если ваша ветвь подходит для вашей работы (например, с хорошим соглашением об именах), каждый будет знать, что его заголовок не всегда стабилен.
В этом виде «рабочей» ветки просто поместите какой-нибудь тег по пути, чтобы указать некоторые «стабильные кодовые точки» (которые затем могут быть запрошены любым тестируемым, который будет развернут). Любая другая версия в этой рабочей ветке просто создана для записи изменений, даже если текущее состояние нестабильно.

Затем вы объедините все в ветке, которая должна представлять стабильное состояние.

Answer 2

Проверьте персональную ветку кода и внесите изменения. По крайней мере, у вас будет некоторый контроль версий для ваших собственных изменений, на случай, если вам понадобится откат. Как только вы освоитесь с состоянием, в котором находится ваша ветвь, объедините эту ветку обратно в ствол.

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

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

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

Редактировать: «Извлечение ветки» относится к созданию ветки в папке веток, а затем проверке этой ветки. Стандартная структура репозитория SVN состоит из папки ствола, тегов и ветвей в корне.

Answer 3

В распределенных системах управления исходным кодом, таких как GIT, вы фиксируете в своем локальном хранилище. Только когда вы нажимаете свой код, он «фиксируется» в удаленном хранилище.

Таким образом, гораздо легче «обезопасить» свою работу между ними.

Answer 4

Либо примите, что код в SVN не находится в полностью стабильном состоянии, и проверьте его в любом случае (и резервируйте время для стабилизации и рефакторинга каждые X дней / недель, чтобы код не слишком сильно ухудшался).

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

Первый вариант не идеален (но лучше, чем отсутствие контроля источника), второй, вероятно, невозможен - третьего варианта нет.

Если у вас нет времени, чтобы привести код в стабильное состояние, у вас демонстративно нет времени на все время ветвления и слияния.

Answer 5

В TFS вы можете создавать «наборы полок» (я не уверен, как они будут называться в других провайдерах контроля версий). Когда вы кладете на полку некоторый код, вы сохраняете его в своем хранилище, но не регистрируете его.

Причина, по которой это важно, заключается в том, что если вы работаете над ошибкой XXXX и исправляете половину кода, но он не стабилен и не «регистрируется», но вы назначены на NewFeature YYYY, вы ДОЛЖНЫ НЕ продолжать работать с той же кодовой базой. Вам следует «заблокировать» свой код Bug XXXX, затем вернуть локальную кодовую базу к последнему зарегистрированному коду и внедрить NewFeature YYYY.

Таким образом, вы сохраняете регистрацию на атомном уровне. Вам не нужно беспокоиться о потере своей работы, потому что она все еще удерживается хранилищем (поэтому, если ваш компьютер загорается, вам не придется разрыдаться), и вы не смешиваете свои исправления для XXXX с вашим новым кодом для YYYY. Затем, как только вас попросят вернуться в XXXX (при условии, что вы отметили YYYY), вы можете просто отменить сборку «полки» и прыгнуть обратно туда, где вы остановились.