Освобождение рабочего процесса от концепций/ограничений CVS

Question

Я переношу наш VCS из CVS в Git, и я все еще стараюсь максимально адаптировать наш рабочий процесс к Git, но у меня все еще есть некоторые сомнения. У нас нет производственной среды, мы периодически выпускаем версии и можем предложить нашим клиентам их развертывание в производственной среде. Поэтому наш рабочий процесс немного отличается от команд. У нас часто несколько версий разрабатываются параллельно, что в какой-то момент необходимо интегрировать с более высокими версиями. Вот простой пример:

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

с V1.0 «закрытым», мы начинаем работать над V1.1. Как мы работали с CVS, у нас была бы ветвь, представляющая HEAD для каждой версии, например. V01_HEAD, создал новую ветвь оттуда, например. V01_00, выполнить некоторую работу, совершить, переключиться на V01_HEAD, слить с V01_00, зафиксировать, пометить, перевести на V02_HEAD и слить V01_HEAD, совершить, перейти на V03_HEAD и слить V02_HEAD, совершить и так далее. Впоследствии мы создадим V01_01 от V01_HEAD и повторим цикле. Как вы можете себе представить, держать все в курсе сложнее, трудоемко, мучительно и слить конфликты очень часто, потому что нам нужно следить за всеми ветвями, находящимися в разработке, и должны быть уверены, что мы не забудем объединиться с одним из верхние ветви. Также очень часто происходит изменение тех же блоков кода в разных ветвях, следовательно, конфликты. Проблемы возрастают, когда мы иногда имеем 4 или более параллельных развития. Единственная цель филиала филиала - служить базой для новых версий. У нас также есть дополнительные проблемы. Представьте, что кто-то работает с V1.12 и выполняет некоторые изменения в нескольких классах. Другие сотрудники работают на V2.5 и другие на V3.0. До V1.12 объединяется, другие версии будут основываться на возможно устаревшем коде.

делает ли это же философия смысла на Git или лучше иметь меньше и более длинные ходовые ветви (например V1, V2, V3 и т.д.) и просто помечать фиксации перед объединением его высших ветвей?

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

Надеюсь, я был достаточно ясен, объясняя проблему.

Answer 1

Да, философия также имеет смысл на Git. Но вы также можете создать другую структуру, так как вам нужно одновременно разрабатывать v1.x, v2.x и v3.x, вы можете создать 3 ветви релиза v1, v2 и v3. Версия v1.0, v1.1, v1.2 и т. Д. Может быть отмечена тегом и сообщением фиксации, поэтому вы можете легко найти их. Для вашей справки есть a successful git branch module (так как ваше требование отличается от этого, если вы хотите применить этот модуль, вы должны внести некоторые изменения).

C1---C2------C3------------------C7 
     \  \     \ 
     \  C6--C8--C10(V2) C9--C11(V3) 
     \   /______________/ 
      C4-----------C5---C12---C13 (v1) 
         |  |  | 
        V1.0 v1.1 v1.2 

И это не обязательно помечать фиксации до слияния, вы можете добавить тег для истории совершить по git tag –a v1.0 <commit id> -m 'message'.