Написание коммитов в качестве индивидуального разработчика?

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

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

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

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

Вот одна из причин: если вы вдруг обнаружите, что что-то было сломано за последние несколько сотен коммитов (возможно, если вы делаете коммит при каждом незначительном редактировании, менее выполнимо, если вы, как и я, делаете только «стабильные» снимки), вы можете легче найдите место, где вы вставили ошибку, если вы написали четкие сообщения о фиксации, а не "исправления ошибок". (Любимая строка коллеги, я полагаю). Конечно, вы можете пойти svn logили использовать SCM, который вы используете, но с другой стороны это должно быть проще.

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

Я стараюсь всегда. Сколько раз ты оглядываешься назад и думаешь: «Чувак, что я делал, когда сделал это изменение». Я делаю все время. 30 секунд написания сообщения могут сэкономить 20 минут работы, которую вы пытаетесь запомнить.

Вы искренне верите, что накладные расходы при наборе от 40 до 80 символов на простом английском языке являются значительными накладными расходами для коммита, или вы ищете оправдание для ленивых?

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

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

• Вы не всегда будете сольным разработчиком.

• В конце концов вы сломаете свою кодовую базу и попытаетесь восстановить ее. Хорошая фиксация сообщений сэкономит вам часы.

• Вы не можете вспомнить, над чем вы работали три недели назад, верно?

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

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

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

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

Я был единственным коммиттером в проекте TXR и сохранил подробный ChangeLog с самого начала проекта. Это близко к 11 000 строк и растет: http://www.kylheku.com/cgit/txr/tree/ChangeLog

(Сообщения коммита в репо являются просто копией того, что идет в ChangeLog.)

[Редактирование 2016 года: по состоянию на середину 2015 года я больше не поддерживаю файл ChangeLog; однако сообщения фиксации записываются в формате, который соответствует соглашениям Git и ChangeLog одновременно. Там такой же уровень детализации, который не вызывает проблем слияния. Файл ChangeLog может быть механически реконструирован из этих комментариев.]

Да, я неоднократно возвращался к старому сообщению о фиксации, связанному с изменением, которое что-то сломало (раскрыло с помощью git bisect). Сообщение помогло мне понять, что я делал.

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

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

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

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

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

Я иногда вносил изменения, когда в середине написания записи ChangeLog я понял, что это будет git reset --hard(отбросить эти бесполезные изменения), а не git commit -a.

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

Вот связанный вопрос, касающийся цели сообщений фиксации: Почему я должен написать сообщение фиксации

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

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

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