Почему мне не следует создавать ветку объектов из другой ветви функций в GIT?

Question

Я давно использую git и поддерживаю ветки master, development и feature.Теперь из-за неудачного слияния в нашей ветке разработки появился плохой код.Итак, мы создали ветку функции из основной ветви для работы с определенной функцией.

После реализации функции мы выпустили эту ветку функции в prodoction, что в идеале нам не следует делать.Но из-за плохого кода в разработке мы выпустили ветку функций в производство.

Сейчас я работаю над новой функцией и хочу новую ветку функций для этой новой функции.

Мой вопрос,

Есть ли какое-нибудь правило большого пальца или лучшие практики, в которых говорится, что не следует создавать ветку элементов из объекта или мастера?

Я не хочусоздать функциональную ветку из другой функциональной ветви или основной ветви, но у меня нет точной причины, почему мне следует избегать этого?

Answer 1

Feature-Branches не плохо, это то, как вы их используете.

В производственной среде вам требуется не более одной ветви для развертываемого кода, а другая - для тестирования.Чтобы отслеживать изменения и работать ли эти изменения, вы можете дополнительно изолировать изменения от ветви DEV.Как вы заметили, кто-то ввел плохой код, так что вы должны это предотвратить.

Возьмите следующий пример:

Основная ветвь - готовая к использованию ветвь кода разработчика - Ветвь тестирования

1. Feature-RevampMonitoring
   • Enhance-SQLAlerts
   • Bug-OSAlerts
2. Исправление совместимости функций
   • Ошибка-VERSIONAWARE

Обратите внимание, чтоФункциональные возможности теперь представляют собой широкие категории кода, а подотрасли - это отдельные спринты.Когда внутренние спринты завершены, мы можем свернуть их вместе в Feature Feature, чтобы доказать их действительность, прежде чем объединиться с нашей веткой Dev, где мы сможем развернуть ее в тестовых средах.

Итак, функции хороши и могут использоваться для инкапсуляции работы, а также для сохранения ее сфокусированности.

Answer 2

Учитывая, что у вас уже есть ветки master, develop и feature, мне кажется, что вы следуете за GitFlow Workflow .В этом случае, если вы работаете над некоторыми исправлениями или улучшениями до последнего выпуска, вы можете создать ветки hotfix, которые разветвляются из ветки master.Цитирование из темы ветви исправлений по предыдущей ссылке:

Ветви обслуживания или «исправления» используются для быстрого исправления производственных выпусков.Ветви исправлений во многом похожи на ветки релизов и функциональных веток, за исключением того, что они основаны на master, а не на development.Это единственная ветвь, которая должна разветвляться непосредственно от мастера.Как только исправление завершено, его следует объединить как с master, так и с development (или с текущей веткой релиза) ...

Это всего лишь предложение для модели ветвления GitFlow, котораяВы можете использовать его, пока вы снова стабилизируете ветку develop.

Единственная причина, по которой я могу придумать, - избегать создания ветви функции из другой ветви функции - это попытка избежать разветвления из нестабильной ветви (которая не является вашейcase), и попытаться сохранить историю немного чистой, следуя GitFlow или подобному рабочему процессу.Но это относительно, потому что то, что у вас есть в конце дня на Git, это связанные коммиты вместо четких веток.Кроме того, нет никаких реальных ограничений, чтобы держать вас подальше от feature веток из любой ветки / коммита в вашем репо.

О вашей ветке разработки, чтобы стабилизировать ее, я бы порекомендовал верните все коммиты до последнего известного стабильного коммита develop, а затем merge заголовок master в ветку develop, если вы уверены, что master стабильно.Это, вероятно, не будет выглядеть красиво в истории Git, но может сделать работу. Будьте осторожны и не нажимайте на изменения, пока не будете уверены в них.