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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

no changes

или

testing

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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