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

30

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

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

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

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

Нажмите Upvote
источник
14
«Я никогда не возвращался и не просматривал свои сообщения о коммитах». Ну, в первый раз, когда вам придется вернуться, вероятно, предоставит вам такую ​​вескую причину. На самом деле, ходя в твоих ботинках, я бы, вероятно, делал тихие коммиты до тех пор, пока не произойдет это первое возвращение
комнат
5
«Я всегда пишу коммиты, даже если я основной разработчик». Вы думаете, что это необычно? Конечно, основной разработчик должен писать сообщения, даже больше, чем другие разработчики (которые уже должны 100% времени).
AlbeyAmakiir
7
Сообщения коммита - чистое золото, когда вы начинаете поддерживать старые версии программного обеспечения, а не только самые новые.

Ответы:

43

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

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

K.Steff
источник
13
+1 за последний абзац. Я считаю, что написание правильного сообщения о фиксации занимает почти нулевое время, так как я всегда знаю, почему я сделал это изменение.
Стивен Дарлингтон
5
Для моего сольного материала у меня есть сообщение коммита, прежде чем я над чем-то работаю. Я делаю маленькую вещь (нацеливаюсь на 30-45 минут ... у меня тут жена и дети!) И совершаю это. Может быть, вы могли бы назвать это фиксацией развития
CorsiKa
52

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

kemiller2002
источник
12
Это также помогает при создании ежемесячного отчета. Список сообщений коммита - отличное начало для отчета
mhoran_psprep
2
Да, и это действительно займет всего один раз, когда вам нужно, чтобы окупить время, затрачиваемое на комментирование.
tzerb
20

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

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

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

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

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

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

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

CodeART
источник
7

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

jmruc
источник
6

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

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

Стив Беннетт
источник
Интересно вернуться к этому ответу. Недавно я занял несколько экстремальную позицию: никаких сообщений о коммите. Но это довольно плоский HTML / JS-проект, в котором я не могу представить, чтобы когда-либо пытался отследить регрессию. Любое усилие, потраченное на написание коммитов, почти наверняка будет лучше потрачено где-то еще (Не все проекты в этой категории!)
Steve Bennett
4

Я был единственным коммиттером в проекте 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.

Kaz
источник
3

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

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

hfitzwater
источник
3

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

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


источник
3

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

Малькольм
источник