Лучшие практики для управления версиями с несколькими проектами
Когда вы делаете:
let a = 1
let b = 2
[a, b] = [b, a]
Вы делаете:
let a = 1
let b = 2[a,b] = (this is the assignment which you doing '[b,a]', but `b` is not defined yet)
5 ответов
Проверить личную ветку кода и внести изменения. По крайней мере, у вас будет некоторый контроль версий для ваших собственных изменений, на случай, если вам нужно откатиться. Как только вы освоитесь с состоянием, в котором находится ваша ветка, слейте эту ветвь обратно в ствол.
Вы также можете проверить ветку для каждой задачи, а не по одной для каждой отдельной задачи. Вы также можете объединить изменения в свою ветку из магистрали, если кто-то изменит магистраль, и вы хотите, чтобы ваша ветка отражала изменения.
Это распространенный способ использования SVN, хотя есть и другие рабочие процессы. Я работал над проектами, в которых я боялся коммитить (возможно, я сломал бы сборку), потому что мы не использовали эффективно ветвление.
Ветвление действительно мощно помогает вашему рабочему процессу, используйте его, пока вы не освоитесь с идеей слияния.
Изменить: ' «Проверка ветки» означает создание ветки в папке веток с последующим извлечением этой ветки. Стандартная структура репозитория svn состоит из ствола папок, тегов и ветвей в корне.
Итак, мой код никогда не находится в полностью стабильном состоянии, в котором я чувствую себя комфортно.
Почему?
Если ваша ветка подходит для вашей работы (например, с хорошим соглашением об именах), все будут знать, что ее HEAD не всегда стабилен.
В такой «рабочей» ветке просто поместите какой-нибудь тег по пути, чтобы указать некоторые «стабильные кодовые точки» (которые затем могут быть запрошены любым тестером для развертывания).
Любая другая версия в этой рабочей ветке создается только для записи изменений, даже если текущее состояние нестабильно.
Затем вы объединяете все в ветке, которая должна представлять стабильное состояние.
В TFS вы можете создавать «наборы полок» (я не уверен, как они будут называться в других поставщиках управления версиями). Когда вы откладываете какой-то код на полку, вы сохраняете его в своем репозитории, но не регистрируете его.
Причина, по которой это важно, заключается в том, что если вы работаете над ошибкой XXXX, и вы исправляете половину кода, но он нестабилен а не «возможность регистрации», но вам назначается NewFeature YYYY, вам НЕ СЛЕДУЕТ продолжать работу с той же базой кода. Вы должны «отложить» свой код ошибки XXXX, затем вернуть локальную кодовую базу на последний зарегистрированный код и реализовать NewFeature YYYY.
Таким образом, вы сохраните атомарность ваших проверок. Вам не нужно беспокоиться о потере своей работы, потому что она все еще хранится в репозитории (поэтому, если ваш компьютер загорится, вы не Затем, когда вас попросят вернуться в XXXX (при условии, что вы отметились в YYYY), вы можете просто убрать с полок свой «набор полок» и сразу вернуться к нему с того места, где вы остановились.
Либо примите, что код в SVN не находится в полностью стабильном состоянии, и все равно проверьте его (и зарезервируйте время для стабилизации и рефакторинга каждые X дней / недель, чтобы код тоже не ухудшился много).
Или заставьте свою команду работать более структурированным образом с минимальным прерыванием разработки, чтобы вы могли проверить хороший код.
Первый вариант не идеален (но лучше, чем без контроля версий), второй это, вероятно, невозможно - третьего варианта нет.
Если у вас нет времени, чтобы привести код в стабильное состояние, у вас явно нет времени на все время ветвления и слияния.
В распределенных системах управления исходным кодом, таких как GIT, вы делаете фиксацию в своем локальном репозитории , Только когда вы отправляете свой код, он «фиксируется» в удаленном репозитории.
Таким образом, гораздо легче «обезопасить» вашу работу между ними.
гораздо легче «обезопасить» вашу работу между ними. гораздо легче «обезопасить» вашу работу между ними.