Как правильно использовать гит, если нужны данные из другой ветки?

Question

[Junior93]

Добрый день.
Ситуация такая, я сделал одну таску в бранче branchOne, сделал мр в мастер и отдал ее на тест.
Начинаю делать новую таску в бранче branchTwo , обнаруживаю что в ней нужен будет код из branchOne, но branchOne еще не протестирована из-за чего не смержена в master.
Как в таком случае лучше быть, создать branchTwo из мастера и туда смержить branchOne, или просто создать branchTwo из ветки branchOne в которой есть нужные изменения ? или вообще черрипикнуть коммиты в branchTwo из branchOne ?
Какие есть плюсы минусы, что вы обычно используете в таких случаях и почему ?

Comments

[shurshur]

Можно было с самого начала делать ветку от branchOne. Можно попробовать сделать cherrypick нужных изменений (если всё аккуратно делать, получится как будто ветка от branchOne).

Но лучше всего, конечно, не писать новый код от неготового предыдущего, не создавать себе проблем на пустом месте. Потому что branchTwo может по итогам тестирования ещё раз меняться, и получишь дурацкую голвную боль по слиянию со своим кодом. Зачем это нужно?

[Aetae]

Ответа нет. Смотришь по ситуации - что теоретически принесёт меньше головняка в будущем - то и выбираешь. Если ветку почти гарантировано смеражат - то можно почковаться от неё\вмерживать её в свою(тут никакой разницы), если нужен небольшой кусочек, а не всё - черрипикать и т.д. С опытом обычно чувствуешь что лучше, но 100% гарантии никогда не получишь.:)

Answer 1

[GavriKos]

А тут скорее не с гитом траббла, а с процессом.
Еслиу тебя две задачи, одна залочена на другую - то почему ты взял залоченную задачу? Жди пока разлочится :-)

Раз уж завезли гитфлоу и тестирование в ветках - то идите с этим до конца ;-)

Answer 2

[Сергей Кузнецов]

Создать ветку от актуального мастера и потом влить в нее нужные правки из другой ветки это нормально.

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

Черипикать опасно. Этим вы можете нечаянно обнулить все доработки первой задачи, которые будут там сделаны позднее.

Answer 3

[Василий Банников]

В зависимости от ситуации:
1. Можно изначально отпочковаться от той ветки
2. Можно сделать cherry pick

Зависит от того, что по логике правильнее: просто какое-то точечное изменение (типа в конфиге адреса потрогал) - cherry pick. Если это развитие фичи из другой ветки - лучше от ветки отпочковываться.

Answer 4

[mayton2019]

Гит всегда разрешает параллельную разработку. Никто не заблокирован никогда.
Другой вопрос, если ты просто сделал бранч из branchOne, то ты сам как-бы принял риски
того что этот бранч еще может изменится.

И в целом это вопрос не про гит а про организацию процессов и риски.

Answer 5

[Vitsliputsli]

создать branchTwo из мастера и туда смержить branchOne, или просто создать branchTwo из ветки branchOne в которой есть нужные изменения ? или вообще черрипикнуть коммиты в branchTwo из branchOne ?

1 и 2 одинаковы, разве что в 1 случае телодвижений больше, такое нужно только если у вас какието внутренние правила создания только из master. А вот 3 отличается.
В 1 и 2 вы забираете всю ветку, т.е. забираете всю фичу. В 3 случае, вы забираете только 1 конкретный коммит. И, именно так это и нужно использовать.
Т.е. если для фичи branchTwo нужен функционал branchOne, то используете 1 или 2 вариант. Если для фичи branchTwo функционал branchOne не нужен, но чтобы заново не писать вы решили скопировать несколько строк из branchOne - то cherry pick.
Проблема 1 и 2 варианта, что branchTwo не может поехать раньше branchOne, они связаны. И если в какойто момент окажется, что branchTwo ой как нужна, а branchOne совсем не нужна, будет весело. А, если в этом случае, вы выбрали cherry pick только нужных технических деталей, но не бизнесового функционала, то таких проблем не будет.
Вообще cherry pick это некий костыль в ситуации, когда вы заранее не выделили общую часть в отдельную фичу (некую branchCommon из который бы уже создали branchOne и branchTwo), т.к. скорее всего еще до branchTwo понятно что это самостоятельная независимая задача.