LINUX.ORG.RU

git: workflow типа lkml


0

0

Читаю lkml.

Наблюдаю, как некий автор постит новую функциональность в виде пачки патчей, читатели lkml патчи критикуют, автор постит исправленные патчи и т.д.

Есть подозрение, что до отправки патчей функциональность коммитилась внутрь одного и того же бранча как попало, тестировалась, и только в самом конце была раздроблена на отдельный патчи. Если это так, то как народ сотню коммитов вида «всё сделал!!!» и «исправил тысячапятую панику» делит на 5-10 патчей? Причём коммиты «всё сделал» скорее всего придётся делить на куски и раскидывать по разным патчам. Вручную через squish это делать IMO сложновато.

После получения feedback'а и внесения изменений опять получается стройная пачка патчей. Это опять результат ручного squash'а?

Кроме этого есть подозрение, что авторов у функциональности много, а отправляющий в lkml патчи lead просто объединяет их изменения, немного допиливая. Как устроена работа в этом случае?

Вобщем хотелось бы почитать описание workflow по использованию git при разработке и отправке патчей в upstream для типичной команды.

Гуглил-гуглил - ничего не нагуглил.

>Вручную через squish это делать IMO сложновато.

После получения feedback'а и внесения изменений опять получается стройная пачка патчей. Это опять результат ручного squash'а?

Создал бранч, в нём reset'нул до основания и аккуратно закоммитил в 5-10 патчей.

Sectoid ★★★★★ ()

В mercurial это делается с помощью mq легко и непренужденно...

Cy6erBr4in ★★★ ()

Причём коммиты «всё сделал» скорее всего >придётся делить на куски и раскидывать по >разным патчам. Вручную через squish это >делать IMO сложновато.


а в чем проблема сделать вручную?
в несколько итераций и сотню комитов можно перетрехнуть.

Сделал rebase -i, увидел весь список в vim,
поменял сточки местами, нужное объеденил, нужное поставил в очередь на редактирование и т.д. и т.п.

Куча патчей сократилась, потом снова rebase -i и так далее.

fghj ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.