1

В проекте есть ветка dev, от которой создаются ветки для фичей, потом эти фичи мержатся в эту ветку и далее в master. Начал работать, создал новую ветку feature1 от dev, сделал пару изменений в стилях, запушил на gitlab, создал мерж реквест. Далее, снова создал новую ветку feature2 от dev, добавил пару изменений в стилях, создал мерж реквест и так несколько раз. Прощу заметить, что во всех созданных мерж реквестах изменения были сделаны только в одном файле! В итоге у меня сейчас 5 мерж реквестов. При мерже одного из них появляется конфликт в других, и это правильно, потому что при следующем мерже одного из мерж реквестов в ветку dev, файл над которым работал начитает отличаться в других мерж реквестах.

Вот схема:

введите сюда описание изображения

Вопрос: нужно ли при создании новой ветки feature2 от ветки dev, получать изменения из предыдущей ветки feature1?

Пока что единственным решением этой проблемы которое приходит в голову, создавать новую ветку feature2 от ветки dev, потом просто пулить изменения из предыдущей ветки feature1. В этом случае во всех последующих ветках будут все предыдущие изменения.

Kromster
  • 13,809
Denisoed
  • 774
  • если она не была замерждена, то не нужно. – KoVadim Sep 14 '18 at 12:31
  • @Denisoed Почитай эту книгу. Страница 67. Там все описано, по твоему случаю. – Vladimir Glinskikh Sep 14 '18 at 12:39
  • А какой в этом смысл? В итоге в мастер-ветке останутся только изменения из feature 5, а всех остальных не будет. – Эникейщик Sep 14 '18 at 12:58
  • @Эникейщик Но как тогда избавиться от конфликтов? Если замержить любую из веток, и после попытаться замержить другую, то по любому будет конфликт, так как в других ветках не будет изменений замерженой ветки. – Denisoed Sep 14 '18 at 13:07
  • А зачем вообще городить несколько веток для изменений в одном файле? – Эникейщик Sep 14 '18 at 13:10
  • @Эникейщик Работаю по задачам, для каждой задачи создаю новую ветку на основе dev. Во всех этих задачах нужно работать с одним файлом style.css. Создаю мерж реквесты после выполнения каждой задачи, потом тестеры начинаю мержить все ветки в dev вот тут и натыкаются на проблему. Я до этого действовал по другому: создал ветку, сделал нужные изменения, сразу отправил в dev, мержи не копились – Denisoed Sep 14 '18 at 13:17
  • Похоже, что вы и сами знаете ответ на свой вопрос, как надо делать, чтобы не было конфликтов :) – Эникейщик Sep 14 '18 at 13:19
  • 2
    Если у вас фичи зависят друг от друга, то вам надо либо начинать новую фичу когда предыдущая закончена и смерджена, либо стартовать новую фичу от предыдущей фичи, а не от дева – tym32167 Sep 14 '18 at 13:19
  • @tym32167 Вот, я тоже так думаю, но не уверен что это правильно =) – Denisoed Sep 14 '18 at 13:20
  • правильного ответа нет в природе, выбирайте тот вариант, что устраивает вас и вашу команду – tym32167 Sep 14 '18 at 13:23
  • @Эникейщик Ветки не мержаться сразу в dev потому что нужно обязательно тестерам пройтись, потом они уже сами мержат. – Denisoed Sep 14 '18 at 13:24
  • @tym32167 Можете расписать вот это "Если у вас фичи зависят друг от друга, то вам надо либо начинать новую фичу когда предыдущая закончена и смерджена, либо стартовать новую фичу от предыдущей фичи, а не от дева " как ответ? вдру кому пригодится – Denisoed Sep 14 '18 at 13:32

1 Answers1

6

Все эти методологии - gitflow, git branching, etc - это не истина в последней инстанции, это просто рекомендации. То есть правильных и универсальных моделей ветвления исходников кода нет. Адаптируйте их для себя.

В вашем случае, если у вас фичи зависят друг от друга, то вам надо либо начинать новую фичу когда предыдущая закончена и смерджена, либо стартовать новую фичу от предыдущей фичи, а не от дева.

tym32167
  • 32,857
  • да согласен, тут проблема в самом процессе, который мы используем. Тестеры не хотят пропускать потенциаль забагованые фичи на dev, поэтому просят не мержить разработчиков =) – Denisoed Sep 14 '18 at 13:54
  • @Denisoed чтобы не пускать баги на дев, надо тестить фичи, а после мерджа тестить их ещё раз и/или делать регулярный (желательно автоматизированный) регресс дева, при этом не забывая про регресс релизов. – tym32167 Sep 14 '18 at 14:23
  • само собой разработчики тестирую свою работу, и уже после этого создают мерж, и пушат. Какой нибудь процесс командной разработки использовали? – Denisoed Sep 14 '18 at 14:29
  • @Denisoed когда я пишу про "тестить фичи" - я подразумеваю, что QA выполняет тестирование. То, что разрабы проверяют свою писанину - это само собой разумеющееся. Мне да, приходилось использовать и git branching, и gitflow, и кастомные способы. Сейчас, например, мы адаптировали gitflow под свои нужды и живем с этим. – tym32167 Sep 14 '18 at 14:41
  • Сейчас мы кстати работаем над одним проектом, где решили отказаться от gitflow, так как посчитали его слишком сложным в нашем случае, но бывает проскакивает мысль, что все таки есть преимущества у него, в виде фичей, и всем этим подходом. Я правильно понимаю, что, методология gitflow или как её правильнее назвать, создаёт новую фичу на основе всех ранее сделанных изменений, даже из веток которые не были ещё замержены в dev? – Denisoed Sep 14 '18 at 14:53
  • если у вас нет причин пользоваться gitflow, можно просто юзать git branching который тоже в фичами, но полегче. Мы так и делали поначалу, когда переезжали с SVN на git и было ещё не ясно, что нам надо, а что нет. По поводу методологии, в gitflow вы создаете фичи от девелоп ветки, но если в конкретной ситуации вам это не подходит, то, как я написал, можно изменить методологию под свои нужды – tym32167 Sep 14 '18 at 14:58
  • спасибо большое =) – Denisoed Sep 14 '18 at 15:00
  • @Denisoed пожалуйста – tym32167 Sep 14 '18 at 15:01