Comments 15
Автоматическая проверка сообщения коммита в моей практике, привела к росту коммитов с текстом типа «111111» ;)
Смысл было городить питон, вы на питоне «эмулируете» баш :)
runBash = subprocess.check_output
Подставлять параметры в командную строчку через .format — ужасно. Если в параметре попадется пробел или более страшные символы (например если какая-то команда сфейлится и выдаст не хэш коммита, а ошибку), может быть много неожиданностей. Нужно передавать команду списком типа [«git», «log», param, "--pretty"].
Формат и смысл комментариев к коммитам очень важен. Но предоставленное решение немного кардинально. На сколько я понимаю, «официально» поменять в Git можно только последний коммит, и то желательно до отсылки на сервер.
Но вот что делать при описанном подходе если программист шлет разом 5 коммитов на сервер, и часть из них не попадают под формат? Отказывать в действии — тратить время программиста на исправление старых коммитов, а это обычным --amend не делается.
При использовании подобной автоматики, я бы отказывал только в случае ошибки в последнем коммите. А о всех проблемных предыдущих слал оповещение ответственным людям, что бы провели воспитательные работы с автором коммитов :)
Но вот что делать при описанном подходе если программист шлет разом 5 коммитов на сервер, и часть из них не попадают под формат? Отказывать в действии — тратить время программиста на исправление старых коммитов, а это обычным --amend не делается.
При использовании подобной автоматики, я бы отказывал только в случае ошибки в последнем коммите. А о всех проблемных предыдущих слал оповещение ответственным людям, что бы провели воспитательные работы с автором коммитов :)
«официально» поменять в Git можно только последний коммит
Почему же? Сообщение можно поменять у любого количества коммитов. В простейшем случае помогает
git reset
, в более запущенных — git rebase --interactive
и то желательно до отсылки на сервер
Реализованный скрипт ведь как раз и не даст плохому коммиту попасть на сервер, и у разработчика будет возможность скорректировать сообщение.
если программист шлет разом 5 коммитов
Если часть из этих коммитов не пройдет проверку, то программисту будет выдано подробное сообщение, в каких коммитах (выводится хэш) и в каких из строчек сообщений проблемы. После чего он поправит все и снова сделает push.
Да, но --amend для изменения последнего коммита придуман, а rebase и прочее, это уже действие в обход. Сообщение поменять можно, но не естественным путем — workaround.
Я не пользовался rebase в своем опыте, но подозреваю, что частые игры с rebase глядишь и приведут к правильному комментарию в коммите, но потерянному куску кода.
Я не пользовался rebase в своем опыте, но подозреваю, что частые игры с rebase глядишь и приведут к правильному комментарию в коммите, но потерянному куску кода.
Менять можно любые коммиты. Каждое изменение — фактически новый коммит, т.к. меняется SHA, ничего страшного.
Отклонять весь пуш — гораздо логичнее, чем выборочно какие-то коммиты применять, какие-то нет.
Поменять месседжи 10 последних коммитов просто — git rebase HEAD~10, нужным комитам поставили «edit» вместо «pick», быстро пробежались и все поправили :)
Отклонять весь пуш — гораздо логичнее, чем выборочно какие-то коммиты применять, какие-то нет.
Поменять месседжи 10 последних коммитов просто — git rebase HEAD~10, нужным комитам поставили «edit» вместо «pick», быстро пробежались и все поправили :)
Может не хватает опыта у меня с advanced Git, что бы отнестись к этому подходу спокойно. Но звучит убедительно, я обращу внимание на такой подход ;)
Для таких как я, будет полезно: git-scm.com/book/en/Git-Tools-Rewriting-History
В моей прошлой конторе мы отправляли на сервер только по одному коммиту, который получался сквошем. Ну и была проверка на правильность комментариев в том числе.
Логично было бы дополнить аналогичным скриптом в `pre-commit` хуке, чтобы он предупреждал о некорректном формате сообщения.
Sign up to leave a comment.
Git. Автоматическая проверка сообщения коммита на стороне сервера с помощью Python