Git. Автоматическая проверка сообщения коммита на стороне сервера с помощью Python

[radi0]

Автоматическая проверка сообщения коммита в моей практике, привела к росту коммитов с текстом типа «111111» ;)

[maseal]

Тут всё дело в отлаженности процесса. У нас в компании за пустые или бестолковые коментарии к коммитам просто коллеги бьют канделябрами.

[radi0]

тоже так решили в итоге, но я про эффект «только автоматического контроля»

[tzlom]

Смысл было городить питон, вы на питоне «эмулируете» баш :)

[nicronom]

Чтобы с чего-то начинать освоение. Кстати, может быть приведете примеры задач, когда баша уже не хватает и есть смысл использовать Python? Спасибо.

[hellman]

runBash = subprocess.check_output

[hellman]

Подставлять параметры в командную строчку через .format — ужасно. Если в параметре попадется пробел или более страшные символы (например если какая-то команда сфейлится и выдаст не хэш коммита, а ошибку), может быть много неожиданностей. Нужно передавать команду списком типа [«git», «log», param, "--pretty"].

[d1pr3d]

Формат и смысл комментариев к коммитам очень важен. Но предоставленное решение немного кардинально. На сколько я понимаю, «официально» поменять в Git можно только последний коммит, и то желательно до отсылки на сервер.

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

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

[nicronom]

«официально» поменять в Git можно только последний коммит

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

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

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

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

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

[d1pr3d]

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

Я не пользовался rebase в своем опыте, но подозреваю, что частые игры с rebase глядишь и приведут к правильному комментарию в коммите, но потерянному куску кода.

[Meredian]

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

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

Поменять месседжи 10 последних коммитов просто — git rebase HEAD~10, нужным комитам поставили «edit» вместо «pick», быстро пробежались и все поправили :)

[d1pr3d]

Может не хватает опыта у меня с advanced Git, что бы отнестись к этому подходу спокойно. Но звучит убедительно, я обращу внимание на такой подход ;)

[d1pr3d]

Для таких как я, будет полезно: git-scm.com/book/en/Git-Tools-Rewriting-History

[dtv]

В моей прошлой конторе мы отправляли на сервер только по одному коммиту, который получался сквошем. Ну и была проверка на правильность комментариев в том числе.

[Yan169]

Логично было бы дополнить аналогичным скриптом в `pre-commit` хуке, чтобы он предупреждал о некорректном формате сообщения.