Журнал сообщений для контроля версий самостоятельно

Question

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

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

Мне случается использовать git, но этот вопрос носит более общий характер.

Answer 1

Вы должны помещать в сообщения такие же значимые, как те, которые вы помещали бы в код, который имеет несколько разработчиков. Как правило, между кем-то еще, смотрящим на ваши изменения через пару дней, нет никакой разницы, и вы смотрите на них через 12 месяцев. В обеих ситуациях есть хороший шанс, что ищущий не поймет, почему было сделано изменение: -)

Я даже зашел так далеко, что использовал надлежащий контроль над изменениями даже для вещей, которые я делаю в одиночку. Это означает, что каждое изменение в базе кода должно иметь либо запрос на изменение, либо отчет об ошибке (с полной документацией).

Это делает мою жизнь намного проще, когда мне нужно понять, почему что-то было сделано. У меня есть лучшее применение для моей «мочалки», чем пытаться запомнить каждое маленькое изменение и почему это было сделано. Намного лучше, чтобы машина помнила это - ее память намного лучше.

И, по моему мнению , если вы не можете быть обеспокоены, делая это правильно, не делайте этого вообще. Просто вернитесь к менталитету ковбойских кодеров и сэкономьте немного усилий.

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

Answer 2

Для меня это зависит от характера исправления. Иногда это всего лишь одно слово. «Резервное копирование» или «копировать изменения». Однако, если что-то, что вызвало у меня много горя, я буду документировать мои изменения более подробно. Если это с открытым исходным кодом, и я не буду там так долго, я очень подробно документирую свои изменения. svn -diff (и затем документировать все мои изменения таким образом ...:)

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

Я предоставлю вам, что «Исправленная ошибка» не очень хороша в журнале изменений, но если это простая ошибка, возможно, это подойдет.

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

Вы потратили 2 часа на исправление ошибки? Ага! Длинное сообщение коммита.

Answer 3

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

Но время от времени я все еще ленюсь (или наполовину сплю) и печатаю что-то вроде "исправил ошибку".