Сообщения о фиксации должны быть записаны в настоящем или прошлом времени? [закрытый]
Используйте bcp (из командной строки) в сетевой файл и затем восстановите ее.
, например,
bcp "SELECT * FROM CustomerTable" queryout "c:\temp\CustomerTable.bcp"
-N -S SOURCESERVERNAME -T
bcp TargetDatabaseTable in "c:\temp\CustomerTable.bcp" -N -S TARGETSERVERNAME -T
- Н используют собственные типы
- ,-T используют доверительное соединение
- -S ServerName
, Очень быстрый и легкий встроить в коде. (Я создал резервное копирование базы данных (восстановление) система вокруг этой самой команды.
7 ответов
Я думаю об этих сообщениях так, как они появляются другим разработчикам. К ним еще не применены изменения, и возникает неявный вопрос: «Что будет делать этот набор изменений / патч?» Он «исправит ошибку XXX в YYY»!
Для других глаголов запись их в виде команды кажется более естественной и работает лучше, если у вас есть конкретная цель заранее - вы можете буквально написать сводку фиксации вместе с up- предварительные испытания перед выполнением работы.
Я не придаю этому большого веса, но для меня это путь наименьшего сопротивления при сохранении последовательности.
Я лично использую прошедшее время («фиксированное»), поскольку к тому времени, когда я доберусь до фиксации, ошибка будет исправлена (иначе я бы не совершил фиксацию).
Я думаю, что писать о текущем коммите в настоящем времени - хорошая идея, потому что это делает его более ясным, когда вы ссылаетесь на предыдущие коммиты в прошедшем времени.
] Я не думаю, что это действительно важно. Цель состоит в том, чтобы:
1) Сообщать о том, что делается или было сделано, чтобы можно было легче находить ошибки, легче устранять проблемы и, как правило, было легче поддерживать проект.
2) Сообщать, какие заявки были исправлено, если таковое имеется, поэтому аудиторы (если они используются в вашей компании, могут видеть, какие изменения соответствуют каким тикетам).
Наконец, если это «уже исправлено,« Исправление »не имеет смысла, и если вы» Если все еще работают над этим, "Исправлено" неверно.
If it is a small commit I use present continuous:
Fixing bug 304
or
Adding comments
If it is a big commit, I do more of a change log:
- Fixes Bug 453, 657 and 324
- Adding Expression syntax
- Refactored the Operator class.
ИМХО, если вы хотите, чтобы это было описательно, без необходимости учитывать контекст, то "Фиксированный" определенно единственный правильный вариант.
Что касается интуитивности - если я взгляну на какой-нибудь журнал изменений, я определенно пойму, что вы имеете в виду исправленную ошибку, поскольку я знаю контекст, в котором используется это слово, но мой мозг уловит это гораздо быстрее, если слово написано на этот способ самоопределения.
«Исправление» - наихудший выбор ИМХО, поскольку его можно интерпретировать не только как описание того, что делает патч (для чего), но и как статус ошибки, что означает, что над ней работают и еще не решены.
« Исправить ошибку X » на 2 символа короче, чем « Исправленная ошибка X ».
И на 3 короче, чем « Исправление ошибки X ».
С точки зрения написания коротких сообщений фиксации настоящее время иногда / обычно сохраняет несколько символов?
Что я на самом деле думаю немного важно, например. с рекомендацией Git меньше 50 символов в строке сообщения первой фиксации.
Кроме того, меньше текста -> быстрее читаете?