Comments 17
А можно TL; DR со ссылкой на даунлоад?
Конечно!
Писать сообщение для коммита – трата времени. Генерировать сообщение для коммита автоматически – экономия времени.
Плагин для Intellij: https://plugins.jetbrains.com/plugin/22770-auto-commit-message
Исходный код: https://github.com/anatolykopyl/auto-commit-message-plugin
Расширением для хрома не делюсь, потому что Jira у всех разная, а расширение сделано именно под наш интерфейс. Да и для IDE плагин лучше.
Вредная штука. Заголовки задач (а особенно багов) далеко не всегда сформулированы в пригодном для коммит-мессаджа стиле.
Не работаю в отделе разработки, откуда Анатолий, но вообще у нас в Selectel команды, как правило, делают шаблоны для постановки задач. Ну и, конечно, если совсем все плохо, заголовок можно отредактировать в самой задаче.
Заголовок бага обычно описывает что не так. Ну там не знаю, "Бесконечно копятся логи приложения". Вы в коммит мессадж так и напишете? Или всё-таки в нём будет "Настроено удаление логов старше недели"?
Почти так и напишем :)
Если это баг, то тип изменения по конвеншну — fix, что отражается в сообщении. Получается «fix(компонент): Бесконечно копятся логи приложения»
Но такой коммит мессадж ничего не говорит о том а что собсна говоря сделано. Может вы их вообще писать перестали.
Подумайте, куда вы, через неопределенный промежуток времени, пойдете смотреть отчет о проделанной работе? Шерстить репозитории, ветки и коммиты или в Jira?
Если вы (и ваш менеджер) используете сообщения коммитов в гите, как основной источник для получения информации о проделанной работе, то скорее всего этот подход не для вас.
Безусловно, не каждая конвенция подходит каждой команде)
Раза 3 перечитал сообщение и так и не понял.
В jira бизнес история изменений - какие таски сделаны, какие баги исправлены.
В git сообщениях - что именно сделано.
Если у вас реализация таски состоит из нескольких коммитов, то у них будут одинаковые сообщения?
"Через неопределенный промежуток времени" все эти джиры теряются/мигрируют/остаются в другой компании. И у вас на руках есть только репозиторий с кодом.
Что-то похоже на обрезанный функционал Tools - Tasks..
Там можно и к jira подцепиться и к redmine и еще десятку сервисов.. видеть список открытых (и не только) задач, создавать на их основе ветку, делать название коммита, передвигать (в небольших рамках) задачи автоматически
Я бы смотрел в сторону хуков гита или автоматизации в гитлабе.
Хуки могут сами добавть нужный текст в сообщение перед созданием коммита.
В гитхабе, можно настроить так, чтобы при мердже все коммиты сквашились в один и заголовок мердже реквеста и описание становилось сообщением этого коммита. Вроде в гитлабе можно настроить похожее. Тогда можно просто сделать CI, которые будет обновлять заголовок и описание.
Генерить текст-предложку перед созданием коммита - идеальный вариант.
Бесконтрольно обновлять что-то там в коммитах на стороне сервера постфактум - адище. Про ребейз и прочие потенциально деструктивные действия хоть кто-то может предупредить, а тут просто замучаешься потом сводить концы с концами
Бесконтрольно обновлять что-то там в коммитах на стороне сервера постфактум - адище
squash and merge это финальное действие в ревью и происходит это один раз. И это скорее ближе к git diff, git apply patch, git commit, чем к ребейзу.
Обновление происходит не в коммитах, а в описании запроса на изменение(Change request). Оно хранится на гитлабе, а не в гите, так-что сводить это с гитом не нужно.
Генерить текст-предложку перед созданием коммита - идеальный вариант
Это вы про хуки?
Есть еще вариант статичный темплейт, гарантий конечно никаких, но зато бесплатно.
git config --global commit.template ~/.gitmessage
Попробую на работе с этим поиграться. У нас строгих требований нет, но с этим будет лучше.
Как потратить дни, чтобы сэкономить секунды: продвинутые коммиты в GitLab