Если я сталкиваюсь с некритической опечаткой в ​​коде (скажем, с ошибочным апострофом в операторе print (error)), стоит ли делать коммит для устранения этой ошибки или ее просто нужно оставить в покое?

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

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

Возможно, вы захотите добавить к TRIVIAL:тегу префикс или пометить его как тривиальный, если ваш VCS поддерживает его.

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

В общем случае: да

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

Просто пойти на это.

Если вы собираетесь отправить релиз ...

... и если вы не лидер команды, то посоветуйтесь с ним .

Относительно содержимого журнала фиксации ...

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

Обычная практика - иметь в своем трекере несколько вечных задач, чтобы отслеживать бесконечные и бесконечные изменения. Например, весьма обычно иметь задачу для:

• большие автоматизированные безвредные очистки (очистка пробелов),
• охота за грамматикой и опечатками,
• модификации системы сборки,
• и т.д...

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

Опечатки должны быть добавлены как коммит. Исправление слов с ошибками или грамматических ошибок повысит читабельность вашего кода.

Использование сообщения фиксации, такого как «Фиксированная опечатка» или «Фиксированная опечатка в file.c», поможет вам отличить эти коммиты от других коммитов с основным кодом.

Да, вы должны сделать это, особенно в начале проекта.

Почему? Два момента:

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

2. Исправить опечатку на раннем этапе и преднамеренно будет гораздо проще, чем исправить ее после того, как было сделано несколько сотен строк вызовов кода / функции. Опять же, временные хаки могут стать полупостоянными на удивление быстро. Вот почему мне приходится иметь дело с объектами, которые имеют методы "CollapseAll" и "ColapseAll".

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

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

Если вы беспокоитесь о склеивании журнала коммитов, значит, вы делаете что-то не так. :-) Частые коммиты - это хорошо! Я постоянно исправляю опечатки. Получить их в кодовой базе как можно скорее и ускорить цикл разработки!

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

Ваш процесс управления изменениями позволяет это?

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

Я бы сохранил изменение, как вы описываете (и на самом деле оно есть - фактически, имя метода неправильно написано, и я его только что обнаружил) на время, когда у меня есть «настоящее» изменение, которое необходимо сделал так же и поставил "исправил различные опечатки" в журнале.

Используйте DVCS для редактирования истории

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

Иметь здравый смысл в противном случае

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

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

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