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

если дописвается - пусть разраб сам думает, но лучше более подроная история, чем её отсутствие

лучше история соответствующая изменениям чем куча мусора в ней

типа "fix typo" или "address code review comments"

лучше история соответствующая изменениям чем куча мусора в ней

история, соответствующая изменениям, а не только конечному результату!

коммит должен соответствовать логическому изменению в коде.

это все вкусовщина, кмк

типа "fix typo" или "address code review comments"

"better name for simpleSequenceFixtureTransport"

коммит должен соответствовать логическому изменению в коде.

да, но если уже закоммитил некоторое время назад - не стиоит менять, так как ты уже выразил свою мысль и она пошла дальше

amend не запрещаю, иноглда полезно

но если пршло несколько минут только

да, но если уже закоммитил некоторое время назад - не стиоит менять, так как ты уже выразил свою мысль и она пошла дальше

форматировать PR перед мерджем в основную ветку - нормально.

нет

как вы раньше жили на vcs, в которых не было squash'а и вообще изменение истории?

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

основная ветка и так содержит только мердж коммиты

вот ты сидишь в ветке и у тебя несколько коммитов и три коммита назад ты опечатался ты добавляешь фикс опечатки и rebase -i твой друг

именно чтобы коммиты были по смыслу, а не по хронологии

вот ты сидишь в ветке и у тебя несколько коммитов и три коммита назад ты опечатался ты добавляешь фикс опечатки и rebase -i твой друг

+1. если этот код не вошел в основную ветку кода - исправлять историю - нормально

именно чтобы коммиты были по смыслу, а не по хронологии

да

вот ты сидишь в ветке и у тебя несколько коммитов и три коммита назад ты опечатался ты добавляешь фикс опечатки и rebase -i твой друг

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

+1. если этот код не вошел в основную ветку кода - исправлять историю - нормально

Нормально. Так же как и не исправлять

дело вкуса

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

Все так

И что?)

И что?)

а то, что коммитьы перестают отражать историю изменений, а начинает отражать что-то ненастоящее

то, чего ты выдумал

а не что делал

Нормально. Так же как и не исправлять

да, проблема в том что гитхаб не предоставляет удобных инструментов для этого процесса.

вот ты сидишь в ветке и у тебя несколько коммитов и три коммита назад ты опечатался ты добавляешь фикс опечатки и rebase -i твой друг

Так а в чем проблема если это будет отдельный коммит с фиксом опечатки?

че вы это трёте и трёте? как тимлид сказал, так и будет ))

сквоши всякие, история. лол

Ну значит еще один аргумент в пользу того, чтобы не менять историю )

а не что делал

Коммиты это не твой отчет перед работодателем

Так а в чем проблема если это будет отдельный коммит с фиксом опечатки?

историю изменений потом читать затруднительно.

а то, что коммитьы перестают отражать историю изменений, а начинает отражать что-то ненастоящее

коммиты отражают историю изменений на уровне проекта.

физические изменения кода в рамках одного логического (фичи \ фикса \ и т.п.) никому кроме отдельно взятого разработчика не интересны. при этом я не говорю что должен быть один коммит на фичу, но коммиты должны отражать осмысленные изменения кода.

Ну и вся идеалогия поменялось только из-за того, что появился git с его возможностью изменять историю?

как до этого жили? mercurial, svn или cvs, прости господи

Коммиты это не твой отчет перед работодателем

конечно, это твой отчет перед собой, чтобы было проще потом искать проблемы

как до этого жили? mercurial, svn или cvs, прости господи

хреново жили. постили код на ревью вне истории SCM, коммитили после апрува одним коммитом.

хреново жили. постили код на ревью вне истории SCM, коммитили после апрува одним коммитом.

да ладно, в mercurial'е весь флоу мог быть таким же, за исключением модификации истории

да ладно, в mercurial'е весь флоу мог быть таким же, за исключением модификации истории

меркуриал прошел мимо меня. но на SVN жили именно так.

а как вы относитесь к тому когда master в feature branch вливают rebase'ом?

а как вы относитесь к тому когда master в feature branch вливают rebase'ом?

позитивно. если feature branch живет долго, периодически хорошо бы его ребейзить с master.

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

позитивно. если feature branch живет долго, периодически хорошо бы его ребейзить с master.

А вот меня дико бесит, что теряется очередность коммитов

Я вообще мержи не люблю, а ребейзы люблю

Вот, например, разработчик решил использовать в своем коде файл, который выпилили в мастере. Так по истории сразу понятно, что код разработчика появился раньше изменений в мастере и понятно что именно мерж мастера сломал код. После rebase'а нихрена не понятно какого хрена разработчик пытался использовать файл, которого уже нет на момент написания кода

и я таких кейсов много встречал, когда rebase сбивает с толку

ну так ты когда ребейзишь, проверяешь код на работоспособность

У тебя ребейз сломается на том коммите, на котором ты пытаешься использовать уже несуществующий файл.

ну так ты когда ребейзишь, проверяешь код на работоспособность

ну это понятно, но если случилось так, что ошибка осталась незамеченной, то потом по истории из-за rebase'а гораздо сложнее разбираться

У тебя ребейз сломается на том коммите, на котором ты пытаешься использовать уже несуществующий файл.

Это почему он сломается?

я его не модифицирую, а просто использую

я его не модифицирую, а просто использую

+

а... ок.

Вообще, основная проблема ребейза - при успехе откатить не всегда получается

Вообще, основная проблема ребейза - при успехе откатить не всегда получается

в смысле?

Вообще, основная проблема ребейза - при успехе откатить не всегда получается

м? git reflog

во-первых да

а зачем вообще в таком случае разбирараться с историей? чтобы ткнуть носом человека и расписать почему именно он мудак?

во-вторых ну боишься, сделай еще ветку

во-вторых ну боишься, сделай еще ветку

+

м? git reflog

git gc

git gc

а нахрена ты делаешь git gc после ребейза?

ERROR: S client not available

во-вторых ну боишься, сделай еще ветку

Ну да, решаемо

а нахрена ты делаешь git gc после ребейза?

Не сразу, потом

Или само

Между ребейзом и откатом может пройти неделя

а зачем вообще в таком случае разбирараться с историей? чтобы ткнуть носом человека и расписать почему именно он мудак?

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

неделю никто ничего не запускал?

ну я обычно проверяю результат ребейза сразу после ребейза.

написал тест, поправил баг, выдохнул

тогда уже придется работать с имеющейся кодбазой. берем бисект, история прямая, все норм

лучше разбираться с покрытием тестами, чем ковыряться в истории гита

ну я обычно проверяю результат ребейза сразу после ребейза.

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

в процессе ребейза

Ох. Что можно сказать, если в команде тебя просят писать log.info("Hello {}, how are you?".format(name)) вместо log.info("Hello %s, how are you?", name)

лучше разбираться с покрытием тестами, чем ковыряться в истории гита

ну то что тесты рулят, никто не спорит. Но тем не менее иногда приходится смотреть историю

Ох. Что можно сказать, если в команде тебя просят писать log.info("Hello {}, how are you?".format(name)) вместо log.info("Hello %s, how are you?", name)

что если все пишут как первое, то правильно просят

в проекте

неделю никто ничего не запускал?

Всяко бывает

Новогодние праздники, другие приоритеты

Ох. Что можно сказать, если в команде тебя просят писать log.info("Hello {}, how are you?".format(name)) вместо log.info("Hello %s, how are you?", name)

попросить писать log.info(f"Hello {name}, how are you?") ?

разве что в логинге используются кастомные фильтры и отдельные параметры должны передаваться явно...

попросить писать log.info(f"Hello {name}, how are you?") ?

Вот тогда ок, но там 3.5 все еще по причинам ?

попросить писать log.info(f"Hello {name}, how are you?") ?

сентри не съест

Ох. Что можно сказать, если в команде тебя просят писать log.info("Hello {}, how are you?".format(name)) вместо log.info("Hello %s, how are you?", name)

Format лучше юзать если нужно одно и то же значение вставить более одного раза, а так не вижу в этом смысла, лучше всего тогда f-string

попросить писать log.info(f"Hello {name}, how are you?") ?

Писать .log("%s", f"блаблабла")

попросить писать log.info(f"Hello {name}, how are you?") ?

https://twitter.com/mitsuhiko/status/1058884261959401472

https://twitter.com/mitsuhiko/status/1058884928543383552

ок ок, понял ) я так не делаю и никогда не буду )

вообще это шутка была ?

да я не к тому, что никогда не делать — просто вспомнил недавний релевантный тред

Кто нибудь собирал скрипты в exe под linux либо osx?

Кто нибудь собирал скрипты в exe под linux либо osx?

в exe??

нет, потому что ни linux ни osx не поддерживают PE формат нативно.