Комментарии 93
Русский менталитeт уже бомбанул в комментах на гитхабе, уж извините за шовинизм:
Ну смотрите. Вы ворвались в чужой репозиторий, к которому не имеете никакого отношения, и рассказываете, что тот, кто сделал этот коммит 6 лет назад, мудак и что-то вам должен.
Где ещё, кроме как на русском форуме, вам объяснят, кто тут на самом деле мудак?
Комментарий добавлен в закладки
Я — автор комментария. Там в проекте 27к коммитов в проекте, а именно этот коммит был сделан на изменение одного символа. Вся информация в сообщении этого коммита без сомнения ценна и полезна, с деталями, с историей, однако она ничего не стоит, поскольку найти эту информацию будет невозможно, так как сообщение в коммите к изменению одного символа является труднодоступной информацией. Проект когда-то заплатил за эту информацию, но теперь она не стоит ничего, поскольку бесполезно барахтается в море из 27к коммитов. Сможет ли найти эту информацию будущий участник проекта, если столкнется с той же ошибкой? Сообщения к коммитам не гуглятся. А если воспользоваться поиском по гитхабу — то будет слишком много информации на выходе, можете попробовать. Вместо того, чтобы писать такое длинное труднодоступное сообщение (файла, к которому был сделан этот "мой любимый git-коммит" уже нет в проекте — modules/router/templates/, поэтому найти этот коммит еще сложнее), можно было бы написать тест, который проверит кодировку в проекте. Можно было бы написать где-то в readme топик с информацией о используемой кодировке и почему.
Я уже несколько раз прочитал фразу "сообщения к коммитам не гуглятся", но до сих пор не могу её понять. Что это значит? Кто ищет коммиты в гугле? Если проблема возникает на проекте, в котором я работаю, то я буду искать информацию через сам git (git log --grep=...), и то же самое написано в статье. И в этом случае подробный commit message будет мне только на руку, т.к. он содержит много слов, потому будет попадать в большое число более-менее релевантных "запросов к git log". Это не "труднодоступность", а, наоборот, высокая доступность информации.
Наверное, имеется в виду, что если искать решение какой-то проблемы в Гугле, то решение, если оно описано в сообщении коммита, никогда не будет показано.
И в этом случае подробный commit message будет мне только на руку, т.к. он содержит много словА зачем эти «много слов» нужны? Изначально программа выводила информацию, что ошибка связана с кодировкой. Это означает что надо не в гугле/гите информацию о проблеме искать, а кодировку проверять.
Большинство программистов при обнаружении проблем используют другой инструмент для поиска решений. Чаще всего это google, или stackoverflow. Очень малая часть программистов (я бы даже сказал, что это исключение из правила) использует git log --grep, когда у них произошла ошибка кодировки при выполнении скриптов в проекте.
Вместо того чтобы оставлять эти знания где-то в истории комитов.
Hу и плюс вброс на обсуждение темы про нафига никому не нужную историю коммитов.
Достаточно, чтобы увидеть грубость ("Are you crazy guys?") и сломанный английский.
Русский менталитeт уже бомбанул в комментах на гитхабе
Я всегда знал, что Линус Торвальдс русский!
Ну камон, какая это документация?
По большому счету весь коммит-мессадж должен был свестись к "заменил непечатаемый символ на пробел", этого всем достаточно и всем ясно, это норма. Нет там никакой проблемы, десятки подобных комитов с еще более аскетичным "fix typo" делаются ежедневно, не та тут ситуация чтобы писать какие-то доки и на отрасль тут уж точно никакого влияния нет.
Автор комита, имхо, молодец, и дело сделал и оставил немного контекста, для таких вот случайных свиделей.
Да, вот только баг-трекер потом меняют или закрывают, и в коммитах остаётся только череда ни о чём не говорящих коммитов типа "JIRA-1234", "JIRA-765" и т.д.
В данном случае мы имеем дело с ситуацией, когда лучше иметь некоторый избыток информации. Ничто не мешает продублировать её и в коммит, и в баг-трекер.
Поэтому соглашусь что неплохо было бы иметь некоторый избыток информации, например добавить заголовок задачи, но копировать абсолютно всё из баг-трекера вплоть до комментариев это уже слишком.
И вот в один прекрасный момент владелец хостинга в очередной раз решает тихо и незаметно поменять условия использования, и все оттуда потихоньку сваливают. Репозитории, конечно, остаются, ведь в распределённых системах полная копия есть у каждого, и вот её залили на гитлаб вместо гитхаба. А в коммитах — "fixed #123", но такого issue на новом месте нет, и ссылка ссылается в пустоту, по ней даже нельзя выяснить, где раньше лежал этот самый 123.
А в чем проблема импортировать тикеты из GitHub в GitLab с сохранением номеров тикетов? Посмотрите на туже Doctrine.
У Magento репозиторий на гитхабе, и они помечают коммиты номером таска в своей _внутренней_ JIRA. Ну, то есть, ты видишь однострочный commit message «MC-12345 Починил вот такую пепяку» и гадаешь, ту ли они пепяку починили…
Вот в этом разница между открытой разработкой проекта и проектом с открытым исходным кодом.
То есть вас смущает, то что проекте с открытым исходным кодом в коммите ссылаются на тикет который нельзя почитать? Как и сказал ilammy, это не проблема git или GitHub в частности.
Какую альтернативу вы предложите в контексте обсуждаемой стати при использовании внутренней JIRA? Описывать в каждом коммите полный текст тикета? И даже если тикет на десятку, сотню или даже тысячу коммитов? А как на счет обсуждений тикета? Их тоже дублировать в сообщении к коммитам?
Есть деньги на образование, интеллект более-менее присутствует. Куда? Программирование — стильно-модно-молодёжно. А дальше по накатанной — тут поработал год, там поработал два, вот уже опыт три года, завёл блог, пишешь о том, как важно создавать хороший код.
В России такого тоже полным-полно, а приедь какой-нибудь таджик сюда, так ему для устройства программистом придётся много чего показывать и доказывать. Но здесь ещё туда-сюда деньги считают, а в богатых странах и с этим полегче.
Так себе показатель. Я сейчас работаю с офисом в Чикаго, из десяти человек, с которыми регулярно контактирую, шестеро — китайцы, и все они подписываются именами типа Dan, Chuck и Paul, потому что у них там так принято.
Но там стоит вполне себе «Стив Ларссон»
— Вы выглядите как японец, а имя-фамилия у Вас типично скандинавские. Как такое вышло?
— Понимаете, когда я иммигрировал к вам в страну, на иммиграционном контроле прямо передо мной стоял скандинав. А когда дошла очередь до меня, пограничник стал заполнять мои документы и спросил, какие у меня имя и фамилия, и я честно ответил: «Таки Еже».
И это аутсорсер не из какой-нибудь страны третьего мира, а из Австралии. Все имена в git log — европейские. Я их теперь навсегда запомнил, и лично для меня теперь Австралия уравнялась со странами третьего мира. Потому что такую дичайшую невежественность как в коде, так и в организации процессов вокруг него, встречал очень редко.
Я вынужден вас огорчить. Как это не прискорбно, но профессиональная IT-культура России одна из топовых в мире. Я правда сравниваю только с Германией, но таких заморочек как в России тут нет и близко. Например, в России микросервисы уже пару лет как вышли из моды, а нам тут месяц назад устроили презентацию «Смотрите! Микросервисы! Как круто! Давайте попробуем?». Пробовать разумеется никто не будет…
Все internal проекты — имеет смысл выносить в трекеры задач всю историю коммуникаций и поиска решения.
А публичные — очень полезно иметь один источник правды.
хорошей практикой является указание в комментарии к коммиту номера задачи из багтрекераКонечно, если коммит имеет отношение к какому-то тикету, номер тикета надо указывать, и это-то обычно не забывают делать. Но коммит не обязательно должен закрывать какой-то известный баг или реализовывать запланированную фичу; кроме того, если на каждый коммит надо глядеть в багзиллу и продираться через портянки комментариев, работать с таким кодом (заниматься археологией) становится очень тяжело.
дублировать эту информацию ещё и в коммит кажется несколько избыточнымРепозиторий — штука вполне самодостаточная, и не стоит гвоздями прибивать к нему багтрекер вместо того, чтобы просто писать нормальные логи. :-)
поэтому обычно в описании к коммиту приводится только то что было изменено в данном конкретном коммитеЧто было изменено понятно и из диффа, зачем же дифф тупо переводить на английский? Хороший лог должен объяснять, почему были сделаны изменения, причем так, чтобы было понятно и без контекста, годы спустя. Собственно, за этим когда-то и придумали правило-совет про 30%-what-70%-why.
Впрочем, это всё в большей степени касается крупных, «долгих» опенсорсных проектов; в случае закрытой коммерческой разработки, где другие приоритеты и циклы жизни кода значительно короче, качество коммит-логов, наверное, не столь важно.
Тут ошибка выше уровнем. Какой-то код тупо ждет US-ASCII на вход, не умея в что-то сложнее 7 бит, и вот его и надо патчить так, чтобы понимал, скажем, комменты на французском. А разраб "просто" сделал так, что тесты проходят (что в принципе не так просто оказалось — найти 0xA0 среди 0x20 можно в хекс-редакторе, но не в большинстве обычных текстовых редакторов).
Это как снабдить стиралку функциями хлебопечки на случай, если кому-то понадобится засунуть туда тесто.
А баг в примере из разряда чертовщины, которая вымораживают мозг просто своим присутствием.
Если не сталкивались, то трудно объяснить тот вагон эмоций, который возникает от ошибок такого рода: ошибка, которой не может быть потому, что не может быть в принципе.
error: unknown start of token: \u{a0}
--> src/main.rs:2:19
|
2 | println!("{}", 42);
| ^
Unicode character ' ' (No-Break Space) looks like ' ' (Space), but it is notА баг в примере из разряда чертовщины, которая вымораживают мозг просто своим присутствием.Вся такая чертовщина возникает на абсолютно ровном месте, из-за чьей-то. Некоторые технологии принципиально не приспособлены для задач для каких их используют. Но обвиняют почему-то чертовщину.
А Вы ещё не выработали привычку, встретив баг при обработке текстовой строки, переключать редактор в HEX-режим, чтобы посмотреть, что за х...hex-ня в строке?
А Вы ещё не выработали привычку, встретив баг при обработке текстовой строки, переключать редактор в HEX-режим, чтобы посмотреть, что за х...hex-ня в строке?Анимешники не смотрят hex коды, анимешники просто читают заклинание
grep --color='auto' -P -n "[^\x00-\x7F]" путь-к-файлуНа ревью порой проще открыть таск и почитать, в чём была проблема, и потом воочию глянуть, как она была решена. А вот как раз имя таска в трекере должно отражать суть проблемы максимально точно.
Я сначала описываю изменения в комментариях к коммитам, потом из этих комментариев собирается описание пулл-реквеста, и в момент мерджа пулл-реквеста есть возможность дополнить и исправить комментарий, если во время обсуждения изменений появилась новая информация.
Не все разработчики работают исключительно с GitHub. Даже open source проекты нередко используют его лишь как зеркало, а главные репозитории хранят у себя под замком. PR и issue — это внешние сущности по отношению к git. И в этом смысле они не сильно отличаются от внешнего баг-трекера.
Ну и, опять же, удобство — это дело субъективное. Мне, например, часто удобнее смотреть код на своей локальной машине, а не через веб. Когда открываешь дифф, например, через git show <hash> | vim -, открываются приятные возможности. Например, большие коммиты можно смотреть по частям и удалять просмотренное. Или открывать в двух окнах редактора дифф и актуальную версию файла, чтобы они были рядом. Или прямо из диффа запускать поиск по Ctrl+]. Куча вариантов, в общем
Ну и, опять же, удобство — это дело субъективное.
Дело не в удобстве, дело в организации процесса. Польза от таких лонг ридов в первую очередь проявляется тогда, когда они ревьювятся вместе с кодом (иначе нет никакой гарантии что этому полотну текста вообще можно верить). Польза на ревью от этого двойная — во первых, ревьюерам не приходится гадать что означает та или иная ревью-дельта, вместо этого они сразу могут начать с чтения такой вот "документации", где оригинатор им все разъясняет, а потом сверять "что написано в доках" с тем "что написано в коде". Это резко увеличивает скорость и качество ревью. Во вторых, ревьюеры могут давать ремарки на "документацию", если им в ней что-то неясно. На выходе получается не просто проревьювленный код, а проревьювленный и полностью задокументированный солюшен.
Но если "документация" — в коммит мессагах, ревьюить ее становится резко сложнее. Мессаг не отредактировать без пересоздания коммита, а амендить коммиты на каждую ремарку от ревьюера — путь к косякам и ненависти.
Да и все равно потом будет squash and merge (в нашей команде) и в коммите останется только ссылка на PR и его title.
Он был зафиксирован в одном из открытых репозиториев Government Digital Service — службы, занимающейся развитием цифровых услуг в Великобритании и поддерживающей проект GOV.UKОчень круто, кстати, что часть «государственного кода» выкладывается в опенсурс, причем не под какой-нибудь непонятной драконовской лицензией, а под простой MIT License.
Представляю коллегу автора, которому нужно ревьювить по 20 коммитов в день.
Рассказ полезный, но место ему действительно в knowledge base и stack overflow.
Вряд ли кто будет искать текст ошибки в гитлоге, или посмотрит историю правок конфига столкнувшись с подобной ошибкой, и тем более вряд ли тут оно поможет поправить парсер.
Если же это было где-то опубликовано, стоит приложить ссылку — там могли откомментить люди с альтернативной точкой зрения или столкнувшиеся с похожей, но другой проблемой. Откомментить же этот опус по существу негде.
! and BREAKING CHANGE footer» стоит точка в конце, настолько это бессмысленное требование.Я сам сначала скептически отнесся к такому подходу, но когда попробовал разные варианты, нашел для себя эти требования удобными. Заглавные буквы и точки создают визуальный шум, например, при работе с GIT в IDE. Понятно, что это правило нельзя буквально распространять на всё, например, на имена классов.
Это как coding style: можно взять за основу то, что нравится и поменять то, то не нравится, и описать свой вариант.
Идея с префиксами мне нравится.
Непонятно только, почему feat и fix — это префиксы коммитов, а не веток. Мой подход: делать бранчи в виде
feat/<scope>/<feature-name>-#<task-id>,
fix/<scope>/<issue-name>-#<issue-id>,
а в коммитах писать по образцу:
[+-*!] <project scope>: <why the change was made> [<task-or-issue-id>],
где [+-*!] — это метки о добавлении/удалении/изменении/важном изменении, <project scope> — какая часть проекта затронута.
Примеры веток:
fix/installation/windows-installer-#12345
feat/authentication/federated-auth-#54321
Примеры коммитов:
+ Installer: components A was missing in Windows installation
- Installer: component Z is obsolete
* Authentication: user name format now conforms specs (#98765)
Нет, эти метки не говорят о том, фикс это или фича. Это лишь некое поверхностное (и опциональное) обобщение того, что человек увидет в diff-ах: было ли что-то добавлено, убрано или изменено. Фикс/фича — это сущности более высокого уровня, для них в идеале должен быть заведён тикет/таск, он может включать множество коммитов добавляющих/удаляющих/изменяющих код, и в идеале это должно происходить в отдельной ветке.
Атомарные коммиты обычно очень маленькие, потому что чтобы сделать фичу, часто нужно сделать это в несколько шагов. Поэтому если "замусоривать" означает "плодить кучу мелких коммитов", то атомарные как раз "замусоривают", т.е. плодят длинную-длинную колбасу коммитов.
возможно, было бы правильнее объединить эти коммиты: так мы показываем, что они имеют отношение друг к другу
Для логического объединения коммитов и предотвращения замусоривания бранчи и сделаны: называем ветку "fix/something", делаем в ней все нужные коммиты, потом сливаем рабочую ветку с мастер-веткой, и там будет коммит "Merged fix/something", по которому понятно, что произошло. Далее, хочешь — смотри только мастер, где "один коммит — один фикс/фича", без замусоривания, а хочешь лезь в ветку и смотри, какие конкретно шаги были сделаны, чтобы имплементировать этот фикс или фичу.
Ну в принципе можно этот мердж-коммит описать по принципам Conventional Commits, а ветку удалить или схлопнуть до одного коммита, но мы обычно сохраняем их, потому что бывает полезно восстановить по коммитам ход мысли и работы.
Это не очень хороший коммит, включаю режим "разрешите докопаться" :)
внедрил несколько тестов
Каких? Почему бы не упомянуть здесь же хеши коммитов? А вдруг не в порядке именно тест — как мне в этом убедиться?
несколько тестов в ветку feature… Они хорошо работали… но при запуске… завершался с ошибкой
Т.е. в нашей идеальной сферической истории появился коммит, в котором сломался билд (добавлен неработающий тест). Появилось место, где git bisect будет спотыкаться, тесты падать. Фикс болтается отдельно. Отсюда вопрос: если так получилось потому что сломанный feature уже смерджили и squash' ить было поздно — то как-то? Если ещё не смерджили, то почему фикс не закоммитили вместе со сломанным тестом?
Целый час моей жизни не вернуть...
Всё оплачено работодателем.
Мой любимый Git-коммит