Почему я должен написать сообщение коммита?

18

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

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

Если я фиксирую несколько раз в день и не закончу функцию, о чем я пишу? Я ТОЛЬКО когда-либо пишу сообщение после многих коммитов, и я чувствую, что пришло время для мини-тега или когда я делаю реальный тег.

Я прав или я что-то упустил? также я использую распределенную систему

user2528
источник
1
Не беспокойтесь, просто скажите «бла» в строке комментария. До тех пор, пока вы никогда не передадите код кому-либо еще, и пока никто не будет работать над ним, и если вам никогда не потребуется откатывать код, и если вы никогда не сделаете ни одной ошибки кода и ... подождите минуту, почему вы снова используете контроль версий?
Майкл Даррант

Ответы:

24

Всем, кто говорит: «Комментируйте только тогда, когда у вас есть полезное, хорошо продуманное сообщение для написания, и когда ваша функция завершена на 100% и у вас есть модульные тесты», я говорю: вы все еще в SVN ,

Если вы используете git , я бы назвал это умным рабочим процессом:

  1. Совершайте так часто, как вам нравится . Напишите любое старое быстрое сообщение там. Никто не увидит это в любом случае.
  2. После, скажем, 10 коммитов, вы завершили ту функцию, над которой работали. Теперь напишите тесты и передайте эти тесты. Или все, что вы хотите. Если вам нравится TDD, сначала пишите тесты, мне все равно, как и git.
  3. git rebase -iначиная с первого «грязного» коммита, который вы добавили, и исправьте свою локальную историю, выдавливая, редактируя, опуская и иным образом очищая вашу недавнюю историю в логические, чистые коммиты с приятными сообщениями .
  4. После уборки попросите кого-нибудь вытащить от вас.
  5. Промыть и повторить.

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

Также обратите внимание, что где-то между шагами 1 и 3 вы можете git pushвносить изменения в свое собственное зеркало репозитория на сервере, чтобы получать бесплатные резервные копии в случае смерти жесткого диска вашего ноутбука.

Алекс Будовски
источник
Хороший ответ, мне это нравится. Я немного боюсь использовать rebase. Вот статья о том, что не так , и как восстановить его bluemangolearning.com/blog/2009/03/...
@acid, если вы отказываетесь от своих личных изменений, не должно быть никаких конфликтов. Кроме того, вы должны попробовать трудно потерять что - нибудь в мерзавца.
Алекс Будовски
4
мой рабочий процесс,
мерзкие
1
@Boris: Потому что он явно говорит о мерзавце, который явно НЕ подрывной
3
Это действительно не должно быть какой-либо значительной работы, чтобы написать предложение, в котором говорится о том, что вы только что сделали, и уничтожение истории с помощью rebase кажется противным. Предположим, вы ввели ошибку в 5-м из этих десяти коммитов, которая не обнаруживается до недели спустя. Возможность связать его с одним небольшим коммитом вам очень поможет.
Gort the Robot
55

Потому что, когда какой-то плохой сопровождающий ищет ошибку и обнаруживает, что она была добавлена ​​в rev. xyz, он захочет узнать что такое rev. XYZ должен был сделать.

Питер Тейлор
источник
38
Ну, тогда он может прочитать 5000 строк спагетти, которые я только что зарегистрировал, ДЖИШ !!! Некоторые люди просто ленивы!
Эдвард Стрендж
9
Потому что, когда бедный присоска придет за тобой (через 3 года), посмотрит на историю и уйдет ... WTF .. WTF ... WTF, он, по крайней мере, будет иметь некоторое представление о том, что происходит. Вы можете легко добавить комментарий типа «обычная проверка, функция X, неполная».
quick_now
3
@ acidzombie24: потому что каждый коммит должен сказать, для чего он был - даже если это «исправленная опечатка в ....», нет смысла в истории ревизий, если вы не знаете, для чего нужны ревизии.
Orbling
11
@quickly_now, бедняга может быть даже ты. К сожалению, это одна из вещей, которую вы должны испытать на себе, чтобы полностью оценить это.
2
@acidzombie - почему вы проверяете неполные изменения ??
Эдвард Стрендж
35

Вы комментируете свой исходный код, верно?

Вы пишете самые лучшие комментарии, те, которые говорят почему, а код только говорит как ?

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

Для любого активного программного обеспечения этот конкретный комментарий будет отображаться в

Гитк - все образцы

(находится по адресу http://longair.net/blog/2009/04/25/a-few-git-tips/ ). Это позволяет с высоты птичьего полета , который работал над программным обеспечением когда это , и что они сделали.

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

оборота user1249
источник
2
@acidzombie, я могу говорить только за git, но вы можете выполнять локальные коммиты очень маленькими шагами, а затем сгруппировать их вместе в один коммит при продвижении вверх по течению. Это сообщение о фиксации может быть описательным.
2
@acidzombie, почему вы делаете это, если не сделали достаточно изменений, чтобы получить комментарий? Пожалуйста, объясни.
2
@Thor: Потому что контроль версий защищает ваш код от потери, и даже наполовину готовый код должен быть защищен.
Бен Фойгт
1
@Ben, коммиты предназначены для длительного хранения и должны точно отражать «куски» работы. Защита от потери, на мой взгляд, ортогональна управлению версиями, и должна обрабатываться подходящей системой резервного копирования. Я обнаружил, что Time Machine для Mac очень хорошо подходит для этой цели - я надеюсь, что аналогичная система доступна для Windows.
2
+1 Я болею за то, чтобы не загрязнять свой контроль источников бессмысленными коммитами. Это облегчает поиск определенного коммита (с помощью полезных комментариев), и я знаю, что когда я проверяю код, он всегда находится в рабочем состоянии. Традиционное программное обеспечение для резервного копирования - лучший вариант для защиты моего локального хранилища промежуточных коммитов. Это хорошо работает с DVCS, но вы должны помнить, что локальная регистрация на самом деле не является резервной копией вашего кода.
Адам Лир
15

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

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

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

  • Рефакторинг пользовательского класса для лучшей инкапсуляции
  • Созданы API-заглушки, чтобы интерфейсы могли использоваться в классе контроллера
  • Преобразовал класс базы данных в абстрактный класс, чтобы в тестовых случаях можно было использовать фиктивную базу данных

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

оборота NickC
источник
1
+1, звучит так, как будто он совершает слишком часто или на плохих остановках. Если он просто хочет получить хорошую резервную копию для некоторых экспериментальных изменений, он может использовать индекс, временную ветвь, изменить предыдущие коммиты вместо создания новых или даже использовать буфер отмены в своем редакторе.
Карл Билефельдт
1
@Karl: IIRC Линус в своем выступлении на git google сказал, что в среднем делается 6 коммитов в день. Теперь я не знаю, сколько будет считаться со многими, но в этом проекте сейчас я сделал коммит, когда у меня появилось какое-то отражение (я зацикливаю правильные данные, я ничего с ним не делаю), после того, как я сгенерировал интерфейс, но до работы сериализации. и сейчас я работаю над тем, чтобы сериализация работала, хотя у меня был интерфейс 2 часа назад. Я сделаю коммит и скажу «Основы рефлексии», как только это сработает, но на первых трех я бы оставил комментарий, когда я легко вижу, когда функция «работает», каждый х фиксирует.
На самом деле я могу сдерживаться, пока не получу какой-то базовый тест, потому что в противном случае, если я прокомментирую каждый коммит, как я узнаю, какой из них имеет стабильное отражение? «основы отражения», «сериализация отражения», «тест сериализации отражения». Предполагается, что сериализация должна быть 2-й или 3-й. Тест может означать юнит тест или тест может означать тестирование, если оно работает на базовых классах, которые мне требуются Я просто думаю, что комментировать имеет смысл, когда я могу сказать «основы работы рефлексии», а не догадываться, какие из них на самом деле означают, что основы работают. Также легче просматривать / находить, когда их меньше читать.
@acid, вся цель коммита - иметь возможность вернуться к нему или сравнить изменения с ним. Если вам когда-нибудь понадобится сделать это с вашими предыдущими коммитами, как вы узнаете, какой из них выбрать? Вам не нужно писать романы, здесь. «Интерфейс работает», «Сериализация работает» и «Работа с отражением» - это просто отлично, на мой взгляд. Не существует фиксированного максимального количества коммитов в день, но если ваши сообщения будут выглядеть как «некоторая работа над интерфейсом», «еще какая-то работа над интерфейсом», «интерфейс почти завершен», то вы делаете коммит слишком часто и вам просто нужно использовать индекс.
Карл Билефельдт
@Karl: Что такое индекс между прочим? Я знаю, что у Гита есть тайник, но я не думаю, что вы говорите об этом. Что оно делает?
12

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

Не делай из них большого дела. Будь честным:

  • «Отредактированные объекты пространственного индекса, Daos и пользовательские интерфейсы для обработки функции X»
  • «Инкрементная регистрация для запроса функции № 1234 и ошибки № 5678»
  • «Я сломал последнюю сборку. Это файлы, которые я пропустил».

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

Скудный Роджер
источник
2
+1 за идею держать его коротким. Коротко и просто и достаточно хорошо, это прекрасно.
quick_now
1
ИМХО, еще лучшим руководством будет общий рецепт "как можно короче, как можно дольше"; так как иногда это просто не возможно держать его коротким , не жертвуя существенной информации
HVR
11

Это уменьшает количество WTF / минуту;)

введите описание изображения здесь

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

Ладья
источник
4
Я бы проголосовал, если бы вы уточнили, почему это так.
SingleNegationElimination
@TokenMacGuy - Извините, я не подписан.
Ладья
1
Как выразительные сообщения фиксации Уменьшают WTF / минуту (они, конечно, делают)
SingleNegationElimination
@TokenMacGuy - я думал, что это было очевидно.
Грач
9

Таким образом, остальная часть вашей команды знает, что WTF проверяет изменения в дереве проекта.

Эдвард Стрендж
источник
7
Я добавляю сообщения коммитов для своих проектов, когда я ЕДИНСТВЕННЫЙ РАЗРАБОТЧИК! Потому что, когда я вернусь через 2 года, чтобы посмотреть на это, я хочу знать, чем я занимался в то время. Я прекрасно знаю, что 99% времени это не будет рассматриваться. 1% времени сэкономит мне 2 недели агонии, и я думаю, что цена ввода 10-секундного коммита стоит долгосрочной выгоды, которую я получу.
quick_now
@quickly_now, даже мучения ? Ваш код такой плохой?
1
@quickly_now: Аминь к этому. В течение года или двух из меня выходит много кода, что каждый последний бит должен был делать месяцами позже, только Бог знает. Боже, и моя история пересмотра.
Orbling
О да. Я тоже согласен. Я думаю об этом как об опыте == смирения.
Майкл Даррант
8

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

no changes

или

testing

для коммитов с более чем сотней измененных файлов (без шуток здесь !!).

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

Стейн
источник
1
звучит как идеальный кандидат на рецензирование перед коммитом, если я когда-либо слышал.
2
о человек, я работал с такими людьми. Сводит меня с ума.
sevenseacat
4

Почему вы делаете, если изменения не имеют смысла?

Просто внесите изменения, которые имеют значение. Например, я провел довольно большой рефакторинг на прошлой неделе, что заняло у меня около 3 дней. У меня было бы множество коммитов за это время. Некоторые из них были довольно небольшими изменениями («переименован в класс X в Y для отражения новой ответственности» или «переместили метод Z () в класс Q»), а другие были действительно большими. Когда я заканчиваю функцию / рефакторинг, я проверяю, можно ли раздавить некоторые коммиты (по крайней мере, git поддерживает это, не знаю о других инструментах), но обычно я оставляю их как есть, потому что это помогает позже.

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

EricSchaefer
источник
3

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

Но, к сожалению, номер ревизии не говорит вам, когда вы изменили X или Y. Поэтому вы можете либо прочитать все коды, принятые за последние N дней, либо просто прочитать подробные сообщения о фиксации, которые вы написали (гораздо более читабельные, чем код).

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

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

GG01
источник
Почему я должен делать это во время каждого коммита, а не в конце дня, через день или когда я заканчиваю функцию?
1
почему вы делаете это часто, если для этого нет «естественной» причины?
Я фиксирую всякий раз, когда делаю какие-либо существенные изменения, чтобы они могли быть отражены в репозитории, и другие разработчики могут проверить эти изменения. Но ответ, который вы дали, помогает с высоты птичьего полета понять, что и кем и когда делается.
GG01
@ acidzombie24 Ну, не делайте наполовину готовых вещей, если вам действительно не нужно. И поэтому другие люди могут видеть, что вы делаете / работаете, когда вы однажды звоните больным, и ничего не работает. Или чтобы вы могли вспомнить, где вы остановились, когда вам приходилось сидеть на собраниях в течение 2 дней. Или, таким образом, вам легче определить, какая ревизия сломала сборку, и посмотреть на различие.
NOS
@ Thorbjørn: Почему бы мне не внести изменения, которые я не хочу переделывать?
3

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

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

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

инка
источник
3

Вы что-то упускаете. Там должно быть причиной для выполнения коммита в противном случае вы бы не делать это.

Все, что вам нужно сделать в комментарии, это изложить причину в словах, даже если это только wip: adding new state objects

Ричард Харрисон
источник
точно. Даже если (как упоминалось ранее) это просто код, который вы не хотите переделывать, очевидно, это что-то значит, поэтому не составит труда написать супербыстрое резюме.
sevenseacat
2

Как и многие другие, я немного программирую в свободное время и использую систему контроля версий, чтобы отслеживать как мою разработку, так и изменения. Количество свободного времени, которое у меня есть, сильно варьируется от недели к неделе и от месяца к месяцу. Во многих случаях у меня не было времени на программирование проекта в течение нескольких недель или даже месяцев подряд, а время, которое у меня было, обычно составляло от 10 минут (обычный день) до 40 минут (хороший день). Это, конечно, не очень хорошие условия - особенно для устранения неполадок.

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

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

Спарки
источник
2

Подумайте об этом логически на минуту. Когда вы совершаете, это значит, что что-то было сделано. Если вы не оставите сообщение, как другие люди узнают, что было сделано?

Sergio
источник
Один взгляд на мой невероятно очевидный код, и они мгновенно узнают все, что он делает, и все удивительные тесты, которые он проходит на 100%. Извините, у меня сегодня настроение юмора [поэтому я ДЕТСКИЙ];)
Майкл Даррант
1

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

Йорис Гир
источник
2
у меня нет соблазна сделать это
1

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

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

Махеш Велага
источник
1

Так, что автор этого кода 1 год спустя знает, кого выследить за этот ужасный код. :)

talonx
источник
Вот для чего blameособенность vcs.
Питер Тейлор