Является ли ссылка на ошибку / проблему в сообщении коммита хорошей практикой?


11

Я работаю над проектом, в котором мы настроили систему управления исходным кодом, чтобы автоматически писать заметки в трекере ошибок. Мы просто пишем идентификатор ошибки в сообщении о коммите, и сообщение о коммите добавляется в качестве примечания к трекеру ошибок.

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

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

Ответы:


10

Мы приняли эту практику, и она работает очень хорошо для нас. Тесная интеграция между системой контроля версий (VCS) и другими системами, которые мы используем, например, непрерывная интеграция, отслеживание ошибок и т. Д., Чрезвычайно важна. Если мы когда-нибудь что-нибудь изменим в будущем, нам, безусловно, придется оценить побочные эффекты, включая связи между VCS и системой отслеживания ошибок.

В общем, я бы посчитал это хорошей практикой. Для некоторых систем отслеживания доступны дополнительные опции и инструменты, например, свойства bugtraq для Subversion (SVN). Это говорит о том, что немало людей видят ценность в этой практике.


13

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

Исправлена ​​ошибка № 123: приложение падало после входа в систему

Тогда у вас все еще есть ссылка из истории коммитов на трекер ошибок - и если трекер ошибок когда-либо будет недоступен, вы все равно сможете увидеть в истории, о чем эта ошибка была.


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

Хорошо, тогда я бы просто оставил все как есть. ИМО, это лучший способ, как вы можете это сделать!
Кристиан Шпехт

1
Да, хорошая мысль. В любом случае, это было мое предположение. Только один идентификатор ошибки / проблемы не достаточно хорош в моем опыте. Глядя на журнал коммитов, вы все еще хотите увидеть, о чем был каждый коммит, например, какова была основная причина этого изменения кода. Иногда сообщение коммита больше относится к технической части, в то время как текст для системы отслеживания ошибок больше ориентирован на пользователей программного обеспечения.
Манфред

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

+1 всегда делай это! Я только взял на себя обслуживание проекта, который заполнен драгоценными камнями типа «это могло быть причиной ошибки 5423». У нас нет доступа к их средству отслеживания ошибок.
Kryptic

2

Это очень распространенная практика, и я нашел ее очень удобной. Я использую TRAC, поэтому я могу прочитать историю кода и перейти к задаче, которая привела к изменению, или прочитать историю задачи и перейти к изменениям кода.

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


2

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.