Иногда, когда мы проверяем историю коммитов программного обеспечения, мы можем видеть, что есть несколько коммитов, которые действительно БОЛЬШИЕ - они могут изменить 10 или 20 файлов с сотнями измененных строк исходного кода (дельта). Я помню, что для такого БОЛЬШОГО коммита часто используется термин, но я не могу точно вспомнить, что это за термин. Может кто-нибудь помочь мне? Какой термин обычно используют программисты для обозначения таких БОЛЬШИХ и гигантских коммитов?

Кстати, является ли внесение множества изменений в целом хорошей практикой?

ОБНОВЛЕНИЕ: спасибо, ребята, за вдохновляющую дискуссию! Но я думаю, что кодовая бомба - это термин, который я ищу.

(1) Бен Коллинз-Суссман : «...« кодовые бомбы ». То есть, что вы делаете, когда кто-то появляется в проекте с открытым исходным кодом с гигантской новой функцией, на создание которой ушли месяцы? У кого есть время для обзора тысячи строк кода? ... »

(2) Дэн Фабулич : «Кодовая бомба, или: Новичок с большими идеями ... Кодовая бомба - это патч, настолько большой, что никто не может его просмотреть».

(3) Google Summer of Code: рекомендации : «Фиксируйте заранее, делайте коммиты часто ... Пожалуйста, не работайте целый день, а затем выталкивайте все в одну бомбу кода . Вместо этого каждый коммит должен быть автономным только для одной задачи который должен быть обобщен в сообщении журнала ".

(4) Джефф Этвуд : «кодовые бомбы ... Правило № 30: не уходи темнее ...»

Мы, вероятно, называем это плохим коммитом . :)

Плохая практика

И да, это, как правило, считается плохой практикой , так как имеет негативные последствия:

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

Приемлемые случаи

Однако могут быть случаи, когда крупные коммиты вполне приемлемы . Например:

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

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

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

Обновление: ответ Дэвида Кэри ссылается на известных ИТ-актеров, использующих термин «кодовая бомба» (наиболее важно, Коллинз-Суссман, первоначальный создатель Subversion ). Вот так (хотя пока не могу сказать, что слышал, если часто).

Кстати, является ли внесение множества изменений в целом хорошей практикой?

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

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

Таким образом, в этом есть нечто большее, чем просто просмотр количества файлов, затронутых в коммите.

Термин, который я слышал, это «короткие проверки» . И я не фанат их. Мне нравятся меньшие коммиты, которые гарантируют, что ничто другое не нарушено на разумном этапе проекта. Большой коммит, как правило, чреват проблемами, которые отражаются в течение некоторого времени, когда это происходит.

Я называю это «типичным SVN коммитом» или «завтра день релиза коммит»

Столько, сколько я люблю SVN, я просто отключен фактом, что я не могу сделать местные коммиты.

РЕДАКТИРОВАТЬ: они обычно имеют слова «вещи» и «пиво» ​​в сообщении фиксации.

ВНОВЬ РЕДАКТИРОВАТЬ: следует как можно больше избегать совершения множества изменений, хотя это не обязательно является плохой практикой. Я считаю, что проще пересмотреть ревизию / коммит, он короткий и лаконичный. (в сочетании с хорошо написанным сообщением о фиксации, см. мой предыдущий редактор для плохого примера)

«Горячий дымящийся кусок кода». :-)

• первоначальная фиксация - проект, который не находился под контролем ревизии, был добавлен в SVN
• рефакторинг - у архитектора есть блестящая идея об изменении имен классов с / на Smurf Naming Convention или об изменении корня иерархии пакетов
• формат кода - архитектор решил изменить отступ кода от 4 до 3 пробелов или изменить окончание строк с Unix на Windows (или отменить)
• Пятничный коммит - Джо всегда целую неделю работает по пятницам в 16:30.
• uuups commit - Тед по ошибке удалил корневой каталог, зафиксировал это, и теперь он снова качает всю файловую иерархию в SVN

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

И разработчики, которые имеют зеленый цвет для VCS, могут забыть разбить изменения на несколько небольших коммитов. Они не забывают совершать, когда выпускают программу команде QA. Что еще хуже, чтобы другие не увидели ошибочный код, они не фиксируют свои действия, прежде чем успешно пройдут тестирование качества. Наконец, они не поняли, что они зафиксировали выходные двоичные файлы, временные файлы и выходные данные компоновщика, которые действительно производят «большой» коммит.