Как лучше выполнять перенос изменений из feature-ветки в develop?

Question

[mindgrow]

Регулярно переношу изменения из feature-ветки в develop ветку (та ветка в которую переносятся итоговые изменения и из которой формируются релизы).

Обычно я брал ветку разраба, сквошил изменения, видел полный набор изменений, ревьювил и исправлял их и формировал итоговый коммит, который черри-пиком переносил уже в develop.
Такой подход нагляден (хоть и всегда мне казалось чем-то костыльным), но есть минусы
• исправления вношу я, а не разраб, что тратит моё время и лишает разработчика дополнительного опыта;
• бывают конфликты слияния, что тратит дополнительное время.

Хочу оптимизировать этот процесс тем, чтобы
1) конфликты решал разраб
2) исправления на основе замечаний вносил разраб

пт 2 как вижу все решают через pull / merge request - мне тут неудобно, что ревью приходится проводить в GitLab. В Visual Studio 2022 не нашёл как посмотреть Merge Request. Смотрел ещё в TortoiseGit. Мне удобнее было бы смотреть изменения в связи с проектом, чтобы в одном окне был и проект и изменения и чтобы можно было переходить по связям. В гитлабе так нельзя.

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

В результате Merge Request + Rebase мне не очень подходит.
Возможно я неправильно их использую?
Посоветуйте как оптимизировать процесс.

Answer 1

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

Тоже думаю что у вас какой-то странный workflow.

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

Чтобы видеть все изменения не нужно ничего сквошить.
Исправления должен делать сам разработчик, зачем вы делаете это за него?
Черипикать тоже непонятно зачем.

бывают конфликты слияния, что тратит дополнительное время

Это тоже забота разработчика. Пусть перед отправкой своей работы на рецензию делает git merge develop и устраняет конфликты сам заранее.

неудобно, что ревью приходится проводить в GitLab.

Что мешает поставить плагин и работать там где удобно?

Comments

[mindgrow]

GitLab Extension for Visual Studio - это плагин для VS 2019. У меня VS 2022. На 19 перейти не могу так как в 19 нет поддержки .net 5, 6

Это тоже забота разработчика. Пусть перед отправкой своей работы на рецензию делает git merge develop и устраняет конфликты сам заранее.

У вас в пулл реквесте тогда будет много изменений помимо изменений из задачи. Вам это код ревью не мешает делать? Когда надо посмотреть +20 файлов, и определить что имеет отношение к задаче, а что нет.

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

mindgrow,

то плагин для VS 2019

Ну и ладно. Для работы он по факту и не нужен.

в пулл реквесте тогда будет много изменений помимо изменений из задачи

Это почему вы так решили? Рецензируем мы то, что пулл-реквест меняет в актульном мастере, а не просто пачку коммитов. Вы смотрите суммарный diff двух состояний, а не каждый коммит из истории тематической ветки. И всё это прекрасно делается средствами Visual Studio без всяких плагинов. Анализируете код и потом просто пишете замечания уже на сайте гитлаба.

[mindgrow]

Сергей Кузнецов, у меня в VS 2022 нет ничего для пулл реквестов. Обновился до последней версии VS 2022 community - ничего не появилось. Хотя в VS 2019 помню что-то было.

Вы используете community или professional версию?

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

mindgrow, вам хочется чтобы VS выполнял функции браузера или всё таки хочется сравнивать ветки в Git? Для второго там всё есть. Это я могу сказать даже не пользуясь VS, так как работаю в других IDE. Git везде одинаков.

Повторю ещё раз. Анализируйте и пишите код в IDE, комментарии оставляйте через браузер. Пулл-реквесты это фича конкретных сайтов, для облегчения процесса рецензирования кода перед слиянием, это не функция гита.

[mindgrow]

Сергей Кузнецов, да, разобрался, вчера сделал ревью через merge request в гитлаб. Очень удобно расставлять замечания merge request через браузер.

[mindgrow]

Сергей Кузнецов, а как можно быть в такой ситуации. Я внёс замечания к мердж реквесту и закрыл реквест. Разработчик исправил замечания и сделал новый реквест.
Чтобы отследить свои предыдущие замечания, мне надо открыть старый и новый реквесты, всё правильно?

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

mindgrow, что значит «закрыл реквест»?
Зачем? Мы закрываем его когда все замечания обработаны и изменения приняты (merged) в проект. Либо если вы полностью забраковали работу разработчика и отказали ему в принятии изменений.

Но сам запрос не удаляется, разработчик может переоткрыть этот запрос и продолжить его дорабатывать. Создать новый он не сможет, так как запрос ассоциирован с его тематической веткой. Мне кажется если он попробует создать новый, то просто переоткроется тот запрос, что уже есть. Невозможно из одной ветки сделать два разных Merge Request.
Следовательно когда он исправит замечания и отправит их (push) то автоматически обновится исходный MR и ничего нового создавать не надо.

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

mindgrow, если всё понятно, отметьте пожалуйста ответ решением.

Answer 2

[mayton2019]

Вот тут с первых слов у меня уже непонятно

Регулярно переношу изменения из feature-ветки в develop ветку (та ветка в которую переносятся итоговые изменения и из которой формируются релизы).

Зачем ты это делаешь? Какова твоя роль? Везде все знать? Если ты лид - сделай code-review отпиши комментарии и пускай отвественный разработчик сам заливает в develop.

А это что?

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

Мне кажется у тебя вообще налицо какая-то ненужная активность. Эти чери-пики и сквоши не надо применять для производтсва кода. Я около 7 лет работаю с git и мы просто обходились обычным merge.

Comments

[mindgrow]

Мои задачи:
- следить за качеством кода и архитектурой
- менторить разработчиков
- готовить релизы
- развивать продукт

Если делать мердж то в develop попадают ненужные коммиты из feature ветки.
В develop каждый коммит должен представлять решение задачи.
Если делать pull/merge request + squash, то review надо будет делать в gitlab, что мне не подходит.

Я около 7 лет работаю с git и мы просто обходились обычным merge.

И что же вы, коммиты из фиче-ветки тянете прям в мастер в том виде как они есть?
Разарботчик делает ежедневные коммиты в свою ветку, под разными описаниями, чтобы фиксировать свою работу и сделать видной для других. Зачем эти коммиты тянуть в мастер?

[mayton2019]

А ну тогда вы все знаете.

Какие советы нужны тому кто ментор?

[mindgrow]

mayton2019, вброс про менторство не понял.

Вы пишете, что используете обычный merge, я ответил, что история мастера из-за этого забивается ненужными записями.
Я правильно вас понял?

[mayton2019]

mindgrow, разработчик может сделать commit amend и убрать ненужную историю. Но всё это - конвенция работы вашей команды. Сделай конвенцию и не будешь заниматься чери-пиками и сквошами.

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

mindgrow,

коммиты из фиче-ветки тянете прям в мастер в том виде как они есть?

Проблема высосана из пальца.
Если разработчик не причесывает историю ветки перед отправкой, или если история изначально подпорчена коммитами слияния, то мы просто делаем squash merge. Это выглядит как схлопывание всей истории ветки в один коммит и cherry-pick его в мастер. Получаем один аккуратный коммит без связи с тематической веткой.