Перейти к содержанию
  • записи
    104
  • комментариев
    125
  • просмотров
    15 606

Работа с системой контроля версий в команде разработчиков


MasterGH

1 463 просмотра

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

 

Можно совместно работать над одним большим проектом через git-flow. Возможно, кто-то из форумчан тоже использует git flow на работе.

 

Цитата

git-flow — это набор расширений git предоставляющий высокоуровневые операции над репозиторием для поддержки модели ветвления Vincent Driessen.

 

Кратко. Модель контроля версии построена на 4 ветках

 

master - релизы
develop - разработка
feature - фичи
hotfix - исравления

 

С develop начинается разработка через копирования в ветку feature.
Над фичей идет работа, а после завершения feature мержится с develop и feature сразу удаляется.
После запланированных изменений develop мержится с master уходя в релиз.
Если возникли баги, то от master создается ветвь на hotfix . После фиксов hotfix мержится с master.

 

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

 

В мастере создаются теги с обозначением версии.

Цитата

Учитывая номер версии МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ, следует увеличивать:

  1. МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения API.
  2. МИНОРНУЮ версию, когда вы добавляете новый функционал, не нарушая обратной совместимости.
  3. ПАТЧ-версию, когда вы делаете обратно совместимые исправления.

Дополнительные обозначения для предрелизных и билд-метаданных возможны как дополнения к МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ формату.

 

Шпаргалка по git-flow: ссылка

Семантическое версионирование : ссылка

1 Комментарий


Рекомендуемые комментарии

Занятно. У меня немного не так - версионирование 2-значное, master выливается в релиз, dev выливается на пред-прод, хотфиксы при этом можно делать в dev, все остальное отпочковывается от dev и имеет имена вида bug_N_name, где N - номер задачи в трекере, name - короткое описание (не больше 2-3 слов), bug - тип задачи (feature, bug, refactoring, typo и тд). Никакой код не сможет залиться в ветку более старшего уровня, если он не покрыт тестами.

Ссылка на комментарий

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
×
×
  • Создать...

Важная информация

Находясь на нашем сайте, Вы автоматически соглашаетесь соблюдать наши Условия использования.