Подскажите, пожалуйста, как вы решаете проблему частичного мерджа с веток

других разработчиков?

Допустим, есть ветка refactor, откуда я хотел бы слить в development какие-то куски кода. Но так же разработчику хотелось бы чтобы у него удобно всё удалялось, что я не выбрал.

Ну и это все было бы неплохо никак друг с другом дополнительно не согласовывать. Т.е. чтобы он в принципе всегда вынужден был делать полный мердж с ветки development, а не только лишь сливать отсутствующие файлы, а старый оставались. Как это все лучше организовать?

Просто мерджишь нужный код в мердж, а с него все мерджат себе

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

здесь описал проблематику. Что именно вызывает вопросы7

Забираете куски кода из refactor в development, затем делаете rebase ветки refactor на development, резолвите конфликты, если будут (а они 100% будут, потому что кусок кода который вы берете из refactor будет отличаться от того что было изначально в ветке refactor на момент её создания) Но вероятность получить множество конфликтов при таком подходе прям очень высокая. Вы уверены что вам нужна отдельная долгоживвщая ветка для рефакторинга?

Забираю куски кода как? Обычным диффом? После этого что? Коммит? Почему именно ребейз? Ну у меня есть ментор, который всё, что ему не нравится, пихает в рефактор ветку, а затем обсуждения в pull request. Весьма удобно получается. Или у вас есть другие предложения? Создавать каждый раз новую ветку это надо напрягаться и постоянно будем забывать какие-то ветки удалять, после чего будет их большая масса. Вспоминать что там в них и удалять будет весьма непросто.

такому ментору бы ментора по гит не мешало найти

Так что вы предлагаете?

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

а насчет вашего вопроса про rebase - в соответствии с вашей задачей ( > старый неизмененный код, но которого нет в development оставался постоянно в refactor и постоянно мозолил глаза при сравнении веток) это вариант решения в книге есть описание и примеры как это работает

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

Так почему не мердж? 🤔

потому что вы не понимая основ git пытаетесь изобрести какой-то сложнореализуемый рабочий процесс.

что происходит при merge и что происходит при rebase ?

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

Merge создаёт отдельный коммит со слиянием. Ребейз применяет каждый коммит по очереди на ветке в которую происходит слив

какое состояние исходной и целевой веток используется при merge и при rebase?

Состояние? Локальное?

А эта ветка с рефактором в основную когда-нибудь мержится? А как этот ментор весь этот рефакторинг объясняет с точки зрения ценности для бизнеса?

Эмм, ну об этом и вопрос. Раньше я делал обычным диффом. Сейчас думаю, что следует мерджить, чтобы удалялось что-то из его ветки. Но он в рефактор мерджит, конечно. Та по разному он объясняет. Это я решаю, что из его идей полезно, а что не очень. Как это относится к моему вопросу?

Если вы втихую хотите как-то из wip-ветки, ни с кем не согласовывая, перенести часть изменений в основную, то это звучит как плохая организация рабочего процесса. Стандартным вариантом было бы попросить автора создать отдельную ветку/МР с нужной частью изменений, чтоб они прошли ревью и тесты, после чего вмержить. Такие просьбы с мотивацией "хочу основать свою фичу на этом изменении" вполне обычны

Вы не ответили на мой первый вопрос. А второй чисто из любопытства, почему ментор он, а решаете что из его идей полезно — вы. Какая-то непонятная иерархия.

И какая ветка в нашем случае это вип? Рефактор? Даже если ментор создаст отдельную ветку без конфликтов, это всё равно не значит, что я приму из неё все изменения. Соответственно, проблематика остаётся

Ответил. Ок переформулирую Эмм, ну об этом и вопрос. Раньше я делал обычным диффом, соответственно, ничего явно не мерджил с его ветки. Сейчас думаю, что следует мерджить, чтобы удалялось что-то из его ветки. Но он в рефактор мерджит, конечно.

Нормально. Менторы могут быть по разным направлениям. А главный разработчик это я

WIP-веткой я назвал ветку рефактора, потому что она не основная и в ней постоянно появляются новые изменения.

То есть ответ "нет, ветка рефактора никогда не мержится и не планирует быть вмерженной в мастер/девелоп/основную ветку", так?

До сегодняшнего момента это было так

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

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

вопрос не про “хочу” а про “как это работает” т.е. почему вы решили что вам в этом сценарии должен помочь merge его изменений к себе

Если вы можете санкционировать, какие изменения будут приняты, а какие нет, то мне не до конца понятно, почему вы проблему с большой головы (другого человека) перекладываете на здоровую (свою). Проблема-то в том, что у вас разработчик занимается бесполезной херней, производя изменения, которые вы никогда не примете. Есть вариант просто забить на это и ничего не делать с его веткой, пусть бесконечно бесполезно висит, пусть с этим разбираются менеджеры. Есть вариант заставить его делать только санкционированный рефактор, сразу с прицелом, что тот будет вмержен как можно скорее. Для этого под рефакторинг заводятся задачи. А задачи стараются делать атомарными и дробить как можно сильнее, по многим причинам. Более атомарными, чем "отрефакторить всё без понятной цели и даже примерного понимания сроков". То есть вместо попыток справиться со следствием, выгоднее попробовать решить саму проблему.

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

Аа, нет, нормально. Там же будут совпадать ветки после мерджа в development по идее. Возможно и без ребейза всё получится

А зачем вам мэнеджить старые ветки ? Но вообще есть список несмерженных веток. Можно просто по пятницам его смотреть и то что неактивно понимать, ветка в git, это просто именованный коммит не более

Ваша главная ошибка - боязнь новых веток, это не проблема, git создан для этих веток, излишество это ваш сизифов труд с диффом : (поставьте gitlab, чтоб удобно было, пару месяцев назад я его в докер за 15 мин работы воткнул (качалось дольше всего)

менеджерить старые ветки? Это какие?

Ну я потом прочитал, вы их не создаете, потому что боитесь что их придется менеджить

скажите, пожалуйста, немного подробнее, как вы видите флоу

Я описал в первом сообщении, ветки под фичи, dev - staging, master production, ревью можно проводить в gitlab, там удобные инструменты.

я имею ввиду поэтапно для гитхаба. Вот, допустим, ментор видит 10 проблем в коде. Создаёт 10 веток под каждую из них? И делает отдельный пул реквест с каждой из них?

master - прод dev - разработка От dev создаёте ветку, делаете в ней изменения Закидываете PR из своей ветки в dev Ментор в этом PR делает ревью, обсуждаете, чёт переделываете и т.д. В итоге PR либо принимается и вливается в dev, либо отклоняется Всё Никаких веток ментор вам создавать не должен

Если github, то вы создаете ветку под фичу, а ментора включаете в ревьюверы, он ваш мерж будет аппрувить или ревьювить,

Дополню, если код уже готовый, то надо не ветку создавать а issue.

Пусть создает тикеты, если вы хотите включить его в ретроспективу только

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

Почему ? Это назывется порядок.

это слишком затратно по времени

А диффы вручную создавать не затратно ? Там три клика

нет

Ну тогда сами, мы вам не поможем, у вас кривой рабочий процесс.