Менеджер чтения контроля версий фиксирует

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

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

Есть социальное или техническое решение для этого?

Дополнительная информация: это проект технического обслуживания, так что есть куча «пришлось сделать A, затем B, затем C, а затем, наконец, приступить к реализации X».

Больше информации: конкретное сообщение о коммите, которое подняло флаг с менеджером, было близко к «включенному лучшему способу X, Y и Z», которое является скорее сообщением рефакторинга, а не простым стилистическим исправлением.

version-control management

— Питер Мортенсен
источник

Возможен ли дубликат Ссылка на ошибку / проблему в сообщении коммита считается хорошей практикой?

— комнат

Я согласен с вашим менеджером. Глядя на двухлетний журнал коммитов, чтобы выяснить, когда что-то изменилось, и видеть коммиты типа «исправлений стиля» чертовски раздражает. Если ваш менеджер не позволяет вам добавлять задачи рефакторинга в систему управления задачами, это совсем другая проблема.

— Gort the Robot

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

— Gort the Robot

^^^ что сказал @StevenBurnap - это очень хорошая практика. Простая возможность ссылаться на идентификатор тикета вместо того, чтобы загрязнять сообщение коммита с подробными объяснениями того, какие есть улучшения стиля или рефакторинг, и почему они желательны, это того стоит. И это еще не все, отслеживание усилий, общение с руководством / QA и т. Д. И т. Д. И не начинайте рассказывать о том, как это удобно, когда баг-трекер интегрируется с VCS / инструментом проверки кода

— gnat

Это полностью зависит от ситуации. Реагирует ли менеджер на члена команды, который тратит 50% своего времени на рефакторинг или на один коммит без ссылки на тикет?

— winkbrace

Ответы:

Есть социальное или техническое решение для этого?

Полагаю, но это не проблема .

Ваш менеджер должен знать, что вы, ребята, делаете. Они должны удостовериться, что вы не выполняете кучу работ, которые не приносят никакой пользы, или почему приоритетным является работа без билетов. В этом нет никакого вреда. В идеальном мире это принесет пользу, потому что ваш менеджер может устанавливать ожидания в бизнесе, чтобы вы могли выполнять всю эту работу без давления или перерыва.

Это становится проблемой только в том случае, если ваш менеджер считает, что следует выполнять только работу с билетами, и исключает необходимость технической работы по очистке билетов. Всегда есть технический долг для очистки. Всегда нужно что-то подправить, потому что вы должны, даже если они не дают четкой, немедленной выгоды для бизнеса.

— Telastyn
источник

Если стилистическое исправление является частью билета, над которым вы работаете, и оно связано, то нет ничего плохого в том, чтобы зарегистрировать его отдельно с тем же номером билета, с которым вы работали, для лучшей идентификации.

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

Во время планирования вы можете просмотреть билеты, связанные с техническим долгом, и прикрепить их к фактическим билетам на техническое обслуживание, которые вы планируете работать таким образом, чтобы сделать их более связанными.

Это поможет вам устранить эти «из ниоткуда» исправления и сохранить все в секрете под категорией конкретных проблем / заявок, над которыми вы работаете.

— AvetisG
источник

Хорошо, но если это тривиальное исправление, то это совершенно глупо.

— Легкость гонки с Моникой

Технический долг 99,99% случаев не является тривиальным изменением. Вот почему я говорю «сделай билет», а не погружайся во что-то еще, что является большим переключением контекста. Если это что-то тривиальное и не связано с тем, над чем вы работаете, вы все равно можете проверить это под именем заявки, над которым вы работаете, с отдельным комментарием. Или, что еще лучше, подумайте о нотации, такой как QFIX, для более простой идентификации в дальнейшем, чтобы у вас не было случайных тривиальных изменений, возникающих без организации.

— AvetisG

Что делать, если менеджер также следит за JIRA за новыми билетами, а затем допрашивает их? он не задается вопросом, когда билеты переносятся из будущего спринта в текущий, но как только кто-то создает новый билет, связанный с техническим долгом, он подвергается сомнению.

— Рудольф Олах

Первая нотация QFIX - это то, о чем вам нужно было бы поговорить в команде перед внедрением. Все дело в общении, вы не просто прыгаете и пишете свои собственные правила. Поэтому сначала поговорите об этом как о команде, а затем, если они не согласны с этим, перейдите к другому решению, которое заключается в том, чтобы проверить его вместе с вашим основным билетом, над которым вы работаете, с отдельным комментарием. Обратите внимание, что, опять же, только если изменение является тривиальным, то есть оно не содержит никаких логических изменений или больших рефакторингов. Безобидные, безобидные, банальные изменения.

— AvetisG

@omouse Вполне может быть, что ваш менеджер занимается микроуправлением или что он должным образом не занимается техническим долгом. Тем не менее, менеджер в конечном итоге несет ответственность за проект в целом и отвечает за сам код, и поэтому в идеале должен быть на каком-то уровне осведомлен о каждой продолжающейся работе и почему.

— Gort the Robot

Это тоже меня беспокоит (без каламбура :).

Самые полезные проверки содержат комментарии, которые уникальны и специфичны не только для того, что изменилось, но и почему. Я иногда заканчиваю тем, что помещал комментарии параграфа.

Я иногда попадаю в ситуации, когда требование UI отскакивает назад и вперед после начала разработки, требуя, чтобы я также существенно отклонял код (да, иногда реальный мир - отстой). В этих случаях я считаю еще более важным, чтобы мои комментарии давали ясность относительно причины отказа и, что более важно, почему код заканчивается там, где он есть. Затем, когда руководство возвращается после разговора с клиентами и хочет знать, почему, я могу показать им, не вспоминая весь опыт по очереди.

— Worrystone
источник