Size: a a a

2021 February 03

RU

Roman Usherenko in pro.git::next
ну и вообще. разруливать в консоли != редактировать в консоли. можно юзать вим как 3-way diff или любой IDE, который это поддерживает
источник

P

Pavel in pro.git::next
Roman Usherenko
ну и вообще. разруливать в консоли != редактировать в консоли. можно юзать вим как 3-way diff или любой IDE, который это поддерживает
Тогда возвращается проблема с разными взглядами тулов на their/ours
источник

P

Pavel in pro.git::next
Ну в общем не суть
источник

RU

Roman Usherenko in pro.git::next
а, ну да
источник

RU

Roman Usherenko in pro.git::next
ну вообще если какой-то тул неправильно пишет ours/theirs, то это проблема тулов, надо фиксить
источник
2021 February 04

f

folex in pro.git::next
Периодически задаю этот вопрос в технических чатах. Наверное уже и тут спрашивал, но вдруг появились какие-то решения!

У меня частенько в GitHub случается так, что делаю пуллреквест PR1, и отдаю его на ревью. Пока идет ревью, я могу успеть сделать еще пару фичей сверху первого пуллреквеста. И приходится создавать еще PR2 и PR3, наследуя их друг от друга. См картинку.

Затем ревью начинается, и мне приходится страдать. Правки нужно ребейзить PR1 -> PR2 -> PR3. После сквош-мерджа PR1, нужно делать git rebase --onto PR1^1 PR2 , и то же самое для PR3 после мерджа PR2. В общем, боль.

Вопрос – есть ли у кого-то решение для обезболивания подобного флоу?
источник

pl

peach lasagna in pro.git::next
folex
Периодически задаю этот вопрос в технических чатах. Наверное уже и тут спрашивал, но вдруг появились какие-то решения!

У меня частенько в GitHub случается так, что делаю пуллреквест PR1, и отдаю его на ревью. Пока идет ревью, я могу успеть сделать еще пару фичей сверху первого пуллреквеста. И приходится создавать еще PR2 и PR3, наследуя их друг от друга. См картинку.

Затем ревью начинается, и мне приходится страдать. Правки нужно ребейзить PR1 -> PR2 -> PR3. После сквош-мерджа PR1, нужно делать git rebase --onto PR1^1 PR2 , и то же самое для PR3 после мерджа PR2. В общем, боль.

Вопрос – есть ли у кого-то решение для обезболивания подобного флоу?
а если pr-родителя не примут?
источник

SH

Serhii Herashchenko in pro.git::next
folex
Периодически задаю этот вопрос в технических чатах. Наверное уже и тут спрашивал, но вдруг появились какие-то решения!

У меня частенько в GitHub случается так, что делаю пуллреквест PR1, и отдаю его на ревью. Пока идет ревью, я могу успеть сделать еще пару фичей сверху первого пуллреквеста. И приходится создавать еще PR2 и PR3, наследуя их друг от друга. См картинку.

Затем ревью начинается, и мне приходится страдать. Правки нужно ребейзить PR1 -> PR2 -> PR3. После сквош-мерджа PR1, нужно делать git rebase --onto PR1^1 PR2 , и то же самое для PR3 после мерджа PR2. В общем, боль.

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

f

folex in pro.git::next
Serhii Herashchenko
ну если чейнджи касаются одного пуллреквеста, то можно просто пушить как обычно, это подтянется в твой пуллреквест и у ревьюверов появиться кнопочка refresh при просмотре кода
В моем случае обычно PR1 добавляет какую-то компоненту, а PR2, PR3, etc добавляют сверху дополнительные фичи в эту компоненту.
источник

f

folex in pro.git::next
Цель – облегчить людям ревью, разделив изменения на более-менее цельные куски, которые можно ревьюить независимо.
источник

f

folex in pro.git::next
peach lasagna
а если pr-родителя не примут?
Ну, тогда PR2 и PR3 тоже не примут :) Зря работал, значит!
источник

f

folex in pro.git::next
PR1, PR2 и PR3 тесно связаны. Если бы их можно было не наследовать, я бы каждый раз начинал новую ветку с main/master
источник

pl

peach lasagna in pro.git::next
folex
Ну, тогда PR2 и PR3 тоже не примут :) Зря работал, значит!
ну, я об этом и говорю.
источник

f

folex in pro.git::next
Ну например (беру из воображения)
PR1 = add /metrics endpoint + tests
PR2 = implement auth on /metrics + auth tests
PR3 = implement /metrics?format={json,statsd} + json-statsd tests
источник

LL

Lama Lover in pro.git::next
Привет, чат
Кто-нибудь знает как просмотреть все диффы в моём любимом difftool-е?
На текущий момент, git difftool запускает программу на каждый изменённый файл.
Мне бы хотелось, чтобы запускалась одна программа (например, vim или meld) в которой в нескольких табах были открыты диффы всех изменённых файлов
Может у кого-нибудь уже есть скрипт для этого или что-то такое?

~/.gitconfig
[merge]
 tool = vimdiff
[mergetool "vimdiff"]
 path = nvim
[difftool]
 prompt = false
источник

АЕ

Александр Епанешнико... in pro.git::next
folex
PR1, PR2 и PR3 тесно связаны. Если бы их можно было не наследовать, я бы каждый раз начинал новую ветку с main/master
ну можно сделать pr отправить его как черновик, сделать всю работу в нём и отдать на ревью.
источник

f

folex in pro.git::next
Александр Епанешников
ну можно сделать pr отправить его как черновик, сделать всю работу в нём и отдать на ревью.
Цель – разбить на несколько ПРов для простоты ревью
источник

f

folex in pro.git::next
у меня есть ощущение что качество^-1, время и кол-во потраченных сил зависят от размера ПРа экспоненциально
источник

АЕ

Александр Епанешнико... in pro.git::next
folex
Цель – разбить на несколько ПРов для простоты ревью
разбивайте на несколько коммитов. это будит почти тоже самое.
источник

f

folex in pro.git::next
Да, это вариант. Но тогда придется заниматься переписыванием истории, схлопыванием мелких коммитов в большой PR-like коммит
источник