Pull to refresh

Comments 15

Автоматическая проверка сообщения коммита в моей практике, привела к росту коммитов с текстом типа «111111» ;)
Тут всё дело в отлаженности процесса. У нас в компании за пустые или бестолковые коментарии к коммитам просто коллеги бьют канделябрами.
тоже так решили в итоге, но я про эффект «только автоматического контроля»
Смысл было городить питон, вы на питоне «эмулируете» баш :)
Чтобы с чего-то начинать освоение. Кстати, может быть приведете примеры задач, когда баша уже не хватает и есть смысл использовать Python? Спасибо.
Подставлять параметры в командную строчку через .format — ужасно. Если в параметре попадется пробел или более страшные символы (например если какая-то команда сфейлится и выдаст не хэш коммита, а ошибку), может быть много неожиданностей. Нужно передавать команду списком типа [«git», «log», param, "--pretty"].
Формат и смысл комментариев к коммитам очень важен. Но предоставленное решение немного кардинально. На сколько я понимаю, «официально» поменять в Git можно только последний коммит, и то желательно до отсылки на сервер.

Но вот что делать при описанном подходе если программист шлет разом 5 коммитов на сервер, и часть из них не попадают под формат? Отказывать в действии — тратить время программиста на исправление старых коммитов, а это обычным --amend не делается.

При использовании подобной автоматики, я бы отказывал только в случае ошибки в последнем коммите. А о всех проблемных предыдущих слал оповещение ответственным людям, что бы провели воспитательные работы с автором коммитов :)
«официально» поменять в Git можно только последний коммит

Почему же? Сообщение можно поменять у любого количества коммитов. В простейшем случае помогает git reset, в более запущенных — git rebase --interactive

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

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

если программист шлет разом 5 коммитов

Если часть из этих коммитов не пройдет проверку, то программисту будет выдано подробное сообщение, в каких коммитах (выводится хэш) и в каких из строчек сообщений проблемы. После чего он поправит все и снова сделает push.
Да, но --amend для изменения последнего коммита придуман, а rebase и прочее, это уже действие в обход. Сообщение поменять можно, но не естественным путем — workaround.

Я не пользовался rebase в своем опыте, но подозреваю, что частые игры с rebase глядишь и приведут к правильному комментарию в коммите, но потерянному куску кода.
Менять можно любые коммиты. Каждое изменение — фактически новый коммит, т.к. меняется SHA, ничего страшного.

Отклонять весь пуш — гораздо логичнее, чем выборочно какие-то коммиты применять, какие-то нет.

Поменять месседжи 10 последних коммитов просто — git rebase HEAD~10, нужным комитам поставили «edit» вместо «pick», быстро пробежались и все поправили :)
Может не хватает опыта у меня с advanced Git, что бы отнестись к этому подходу спокойно. Но звучит убедительно, я обращу внимание на такой подход ;)
В моей прошлой конторе мы отправляли на сервер только по одному коммиту, который получался сквошем. Ну и была проверка на правильность комментариев в том числе.
Логично было бы дополнить аналогичным скриптом в `pre-commit` хуке, чтобы он предупреждал о некорректном формате сообщения.
Sign up to leave a comment.

Articles