Иногда, когда мы проверяем историю коммитов программного обеспечения, мы можем видеть, что есть несколько коммитов, которые действительно БОЛЬШИЕ - они могут изменить 10 или 20 файлов с сотнями измененных строк исходного кода (дельта). Я помню, что для такого БОЛЬШОГО коммита часто используется термин, но я не могу точно вспомнить, что это за термин. Может кто-нибудь помочь мне? Какой термин обычно используют программисты для обозначения таких БОЛЬШИХ и гигантских коммитов?
Кстати, является ли внесение множества изменений в целом хорошей практикой?
ОБНОВЛЕНИЕ: спасибо, ребята, за вдохновляющую дискуссию! Но я думаю, что кодовая бомба - это термин, который я ищу.
cluster f...
Ответы:
(1) Бен Коллинз-Суссман : «...« кодовые бомбы ». То есть, что вы делаете, когда кто-то появляется в проекте с открытым исходным кодом с гигантской новой функцией, на создание которой ушли месяцы? У кого есть время для обзора тысячи строк кода? ... »
(2) Дэн Фабулич : «Кодовая бомба, или: Новичок с большими идеями ... Кодовая бомба - это патч, настолько большой, что никто не может его просмотреть».
(3) Google Summer of Code: рекомендации : «Фиксируйте заранее, делайте коммиты часто ... Пожалуйста, не работайте целый день, а затем выталкивайте все в одну бомбу кода . Вместо этого каждый коммит должен быть автономным только для одной задачи который должен быть обобщен в сообщении журнала ".
(4) Джефф Этвуд : «кодовые бомбы ... Правило № 30: не уходи темнее ...»
источник
Мы, вероятно, называем это плохим коммитом . :)
Плохая практика
И да, это, как правило, считается плохой практикой , так как имеет негативные последствия:
Приемлемые случаи
Однако могут быть случаи, когда крупные коммиты вполне приемлемы . Например:
Поэтому, когда это возможно, предпочитайте типы фиксации «хирургического удара» (и связывайте их с идентификаторами задач в вашем трекере!). Если у вас есть веская причина, продолжайте.
Кроме того, я на самом деле не знаю и не думаю, что когда-либо слышал специальное название для большого коммита. Монстр-коммит? Толстый коммит?
Обновление: ответ Дэвида Кэри ссылается на известных ИТ-актеров, использующих термин «кодовая бомба» (наиболее важно, Коллинз-Суссман, первоначальный создатель Subversion ). Вот так (хотя пока не могу сказать, что слышал, если часто).
источник
Что ж, не рекомендуется долго хранить изменения, внедрять различные функции и исправлять ошибки, а затем фиксировать их, что может стать одним из способов получения больших изменений.
Это может произойти иначе, если рефакторинг изменит сигнатуру широко используемой функции, и тогда все они должны быть изменены. Это не обязательно плохо, и я бы не хотел, чтобы разработчики воздерживались от очистки кода из-за страха пересечения какого-то порога.
Таким образом, в этом есть нечто большее, чем просто просмотр количества файлов, затронутых в коммите.
источник
Термин, который я слышал, это «короткие проверки» . И я не фанат их. Мне нравятся меньшие коммиты, которые гарантируют, что ничто другое не нарушено на разумном этапе проекта. Большой коммит, как правило, чреват проблемами, которые отражаются в течение некоторого времени, когда это происходит.
источник
Я называю это «типичным SVN коммитом» или «завтра день релиза коммит»
Столько, сколько я люблю SVN, я просто отключен фактом, что я не могу сделать местные коммиты.
РЕДАКТИРОВАТЬ: они обычно имеют слова «вещи» и «пиво» в сообщении фиксации.
ВНОВЬ РЕДАКТИРОВАТЬ: следует как можно больше избегать совершения множества изменений, хотя это не обязательно является плохой практикой. Я считаю, что проще пересмотреть ревизию / коммит, он короткий и лаконичный. (в сочетании с хорошо написанным сообщением о фиксации, см. мой предыдущий редактор для плохого примера)
источник
«Горячий дымящийся кусок кода». :-)
источник
источник
Обычно многие люди склонны делать большие коммиты, используя централизованную VCS, особенно на сервере, обеспечивающем правильную политику коммитов. То есть коммит должен пройти все тесты, а тесты занимают больше времени (дольше, чем несколько секунд). Поэтому разработчики не хотят ждать так долго, чтобы фиксировать несколько раз и разбивать изменения на несколько небольших коммитов.
И разработчики, которые имеют зеленый цвет для VCS, могут забыть разбить изменения на несколько небольших коммитов. Они не забывают совершать, когда выпускают программу команде QA. Что еще хуже, чтобы другие не увидели ошибочный код, они не фиксируют свои действия, прежде чем успешно пройдут тестирование качества. Наконец, они не поняли, что они зафиксировали выходные двоичные файлы, временные файлы и выходные данные компоновщика, которые действительно производят «большой» коммит.
источник