Управление версиями Git npm во время потока разработки

Вот мой процесс разработки проекта:

  • Функция / feature1
  • Функция / feature2
  • функция / и т.д ..
  • мастер
  • производство

Я разрабатываю свои функции на ветвях функций, когда я закончил работу с веткой, я объединю ее на master и удаляю ее через github ui. CircleCI обнаруживает слияние и развертывание мастера на промежуточном сервере. Позже я объединять вручную ведущую ветвь на производственную, а CircleCI развертывается на моем сервере производств.

Я хотел бы, чтобы моя версия package.json ударялась каждый раз, когда я соединяю ветвь функции с главной ветвью (через интерфейс github). Но я понятия не имею, если

  1. Гитуб разрешает это делать (если да, пожалуйста, объясните мне?)
  2. Это хороший процесс

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

Не стесняйтесь критиковать мой способ продолжить и сказать мне свое. 🙂

спасибо

Solutions Collecting From Web of "Управление версиями Git npm во время потока разработки"

  1. Я не думаю, что Github предлагает такую ​​функцию. Но есть некоторые модули grunt, которые делают это во время сборки. Возможно, вы можете создать скрипт или создать файл make, который сделает это и для вас.

  2. Я не думаю, что это хороший способ управления версиями. После того, как вы закончите с функцией, вы должны решить, являются ли внесенные вами изменения незначительными или крупными. Иногда вы можете совершать нарушения. Просто увеличивая число версий с 1.0.1 до 1.0.2 или скажем от 1.1.0 до 1.1.1 (каждый раз), не будет передаваться величина этих изменений. Лучшая практика. Версии программного обеспечения . Лучшие практики для управления версиями уже описаны здесь.

Я управляю версированием вручную, когда я работаю. Перед каждым выпуском мы создаем тег (v1.0.3, v1.1.4..etc), а затем создаем выпуск в Github. В описании выпуска мы помещаем все новые коммиты. Прохождение сообщения фиксации дает нам хорошее представление об изменениях, которые были сделаны. Если изменения связаны только с исправлениями ошибок и дополнительными дополнениями, мы будем увеличивать второстепенное число, т.е. 1.2.1 – 1.2.2. Если добавлена ​​основная новая функция, мы увеличиваем основной номер версии, т. Е. 1.2.2 до 1.3.0. Когда мы добавляем много изменений, мы переходим от 1.3.0 до 2.0.0. Иногда мы теряем контроль версий. Наш API не является общедоступным, и единственная причина, по которой мы используем управление версиями, – это развертывание и откат. Если вы ожидаете заставить вас работать с открытым исходным кодом и ожидаете сделать вашу работу доступной через какой-то менеджер пакетов, например, npm, вам следует строго следовать за версией semver.