На работе у нас есть модель ветвления GIT, где каждая основная версия нашего продукта имеет отдельную ветвь.
В ветке V2.0 содержатся все коммиты, которые есть в ветке v1.0, плюс дополнительная работа, выполненнаяна v2.0 продукта.V3.0 содержит все коммиты с v1.0 и v2.0, а также дополнительную работу, проделанную на v3.0 и т. Д.
При внесении исправления / функции необходимо перейти от правильной версии продукта, гдеИсправление / функция должна быть реализована.Через некоторое время вы захотите переназначить свою ветку функций поверх последних изменений из любой ветки, из которой вы вышли.Единственная проблема: довольно легко ошибиться и выбрать неверную ветку версии (например, v2.0 вместо v1.0).Вы также не получите никаких конфликтов, потому что все ветки более новой версии содержат все коммиты из веток более низкой версии и дополнительные коммиты.
Я работаю над GIT-хуком (pre-rebase), который будет предупреждатьпользователь, которого он / она, вероятно, перебазирует поверх неправильной ветки версии.
То, что я до сих пор придумал, - это сравнение тегов между локальной веткой функций и удаленной веткой.Как ветка v1.0 имеет тег v1.0, так и ветка v2.0 также имеет тег v2.0.Так что, если пользователь хочет перебазировать ветку функций, разветвленную от v1.0 поверх v2.0, есть разница в тегах.
Однако это не будет работать, если разработчик разветвится из v3Ветвь .0, но пытается перебазировать свою ветку поверх главной ветки, так как в основной ветке нет дополнительных тегов, которых нет в ветке v3.0.
Следующее лучшее решение, которое я могвычислил количество коммитов, которые удаленная ветвь, над которыми пользователь пытается перебазировать, находится впереди.Вероятно, что если пользователь отошел от v1.0, но пытается перебазировать поверх v2.0, v2.0 содержит сотни коммитов, которых нет в ветви функций разработчика.
Мне было интересно, может ли кто-нибудь придумать лучшее решение для предотвращения перебазирования / слияния неправильной ветки версий в ветку функций?
Редактировать: мы не можем установить какие-либо серверные Git-хукив данный момент.Сейчас мы будем делиться с разработчиками git-хуками.(зная, что это не гарантирует 100%, что неправильных слияний не произойдет.)