Получается, после мерджа сделать софт ресет до состояния до мерджа.

А правки выбирать из поля с созданием коммита? После того же, как все было выбрано, делать стеш, а затем перемещаться к коммиту, после мерджа в development? А оттуда уже делать анстеш и коммит?

Выглядит невероятно громоздко, но вроди как должно сработать

Вообще не понял твоей идеи, почитай как что такое CI

при чем тут он вообще? что именно непонятно в моей идее?

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

подкорректировал немного сообщение, где описал проблематику. Посмотрите, может сейчас понятнее будет?

Ну я не вижу, что ваш вариант проще, чем мой

Почитайте это моё изначальное решение

Почитал. После мержа чего куда вы планировали ресетать?

Я вот не уверен что soft reset на предыдущий коммит при merge сработает именно так как ожидается

После мерджа рефактора в девелопмент.

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

Ну т.е. вы предполагаете что все изменённые в wip ветке файлы по soft reset останутся в вашей ветке в их актуальном для той ветки состоянии, как если бы это был ваш обычный коммит, верно?

Мердж будет сделан после обсуждения в пул реквесте

Вроде как да. Если я правильно понял, что вы сказали

Попробуйте, конечно, ради эксперимента. Но это, насколько помню, не должно сработать таким образом.

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

А в чём проблема то? Вроде как до любого коммита можно софт ресет сделать.

Верно

А последующее удаление нежелаемых правок тоже пройдет через ревью и тесты?

Не понял. Какое последующее? Куда и откуда?

Которое после мержа рефактора "как есть".

Это пока не так важно. Тут в ожидаемом результате по soft reset уже, вероятно, проблема будет. Надо смотреть документацию.

Аа, ну это уже от меня зависит. Это же моя ветка. На всякий случай уточню, что продакшн ветка у меня отдельно.

Какая?

Ваша ветка = девелоп?

Да

А в каком плане она ваша? Мол, вы фичи пилите и просто пушите в свою ветку девелопмента без ревью, потому что это ваша ветка?

Верно

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

Да, в продакшн ветку без пул реквеста нельзя

А кто ревьювит такие ПРы?

Я и он

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

Да, но как правило я никого не спрашиваю и я уверен, когда я что-то в прод сливаю

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

Всё верно, в основном я сольно работал

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

Похоже больше на одного + chatgpt с возможностью коммитить

так что в итоге? есть ещё какие-то толковые идеи, как организовать рабочий процесс нам с ним?

Не зная ваших требований и пожеланий к процессу, можно дать только общие рекомендации, резюмировав свои сообщения: * вам было больно от долгоживущей ветки с рефакторингом -> подумайте над тем, чтоб делать ветки короткоживущими и с как можно меньшим количеством кода. Типа одну простыню диффа с рефакторингом куда сложнее просмотреть с той же тщательностью, чем его же, но разделенного логически на два ПРа. * если хотите попробовать воспроизвести процесс, близкий к общепринятым — можете попробовать вести разработку не напрямую в девелопе, а так же в короткоживущих фичеветках, которые ревьювил бы второй человек, как минимум чтоб он был в курсе, что там у вас происходит. Конечно, если вы условно наняты на фуллтайм, а он нанят на например пять часов в неделю, то смысла в этом было бы меньше из-за возможной задержки. * можете ознакомиться во всякими популярными моделями ветвления типа tbd (но не git flow), вариации которых часто принимают в компаниях, и узнать, какие проблемы они призваны решать.

да, спасибо. Я в курсе об этих общепринятых подходах. Но я имел ввиду идеи по моей исходной задаче. Когда 2 долгоживущих ветки.

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

У проблемы xy обычно нет решений при сохранении x и y неизменными

Проблема ХУ — это ж про другое, когда решают проблему Х способом У, с которым проблемы, и вопрошают о решении проблем с У. Здесь же участник чата вроде не пытается весь процесс поменять.

Примерно это здесь и есть. Не меняя ситуацию с ветками, найти решение (в идеале), которое изначально предполагает отсутствие долгоживущих веток

Ненене, проблема ХУ — это про ненамеренное утаивание важного контекста (Х) при фактическом объяснении У. Здесь же участник чата пытается решить проблему, которая является следствием субоптимального рабочего подхода, но он не утаивает никакую информацию, а именно что хочет решить проблему, не меняя общий подход.

Vitaliy Ponomarev
Я бы всё же сказал что потеря (либо умалчивание ча...

Допустим. Что в той ситуации было проблемой Х?

Изначально сломанный workflow

Все множатся из dev, dev fast-forward в мастер и ci на дев сервера, вообще от проекта должно немного зависеть и от вашего пайплайна деплоя.