О состоянии проекта pivotal_shell
December 24, 2011 in ProjectsГод назад я сделал полезную утилиту pivotal_shell, предоставляющую интерфейс командной строки для Pivotal Tracker.
Причин на то было две: во-первых, сайт Pivotal Tracker был невероятно медленным, во-вторых, нужно было в текст коммита в Git дописывать код задачи из Pivotal Tracker, к которой он относился.
В двух словах – pivotal_shell я больше развивать не буду.
Если кто-то хочет подобрать проект и двигать его дальше, напишите мне письмо.
(А к самой задаче облегчения коммита я так и не добрался – ее сделал Богдан Гусев, однако совсем не так, как я это себе представлял.)
Причина
Причина в том, что первоначальные причины перестали быть актуальными.
За прошедший год браузеры стали быстрее, да и ребята из Pivotal Labs поработали над оптимизацией трекера. Плюс, я сменил ноут. :) Теперь производительность веб-интерфейса Pivotal Tracker меня полностью устраивает. Даже ссылки на задачи можно открывать в одной и той же вкладке благодаря расширению Pivotal Faster (за которое спасибо Ярославу).
Кроме того, у меня поменялся подход к проблеме №2 (с гитом), поэтому необходимость в такой утилите отпала.
Мой подход к указанию кода задачи в коммите
- Спокойно себе коммичу в гит с любыми комментариями.
- Непосредственно перед
git push, то есть перед заливкой коммитов в общую кучу, делаюgit rebase -i, и…- Собираю все коммиты в один (или несколько, если затронуты разные задачи)
- Подписываю (каждый) получившийся коммит номером задачи.
- Делаю
git push.
Преимущества
- В неэкстремальных условиях оформлять коммиты приходится раз или два в день.
- Кроме того, лог получается чище и нагляднее.
- Я могу коммитить так часто, как мне этого хочется, не отвлекаясь на бюрократию.
Риски
- Можно прозевать и запушить неоформленные коммиты.
Кстати, поэтому я считаю, что проверку на наличие кода коммита, как и любую другую валидацию формата сообщения о коммите, нужно делать на стороне сервера.
Понравился пост? Купи мне кофе