Как называется действительно БОЛЬШОЙ коммит исходного кода? [закрыто]

37

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

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

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

Ида
источник
15
«Взломать совершить». :-)
Питер К.
3
Лично я бы назвал коммит такого размераcluster f...
Ramhound
1
Мой босс делает это все время. Комментарий к регистрации: "все; о)"
MetalMikester
+1 за вопрос, потому что я люблю каждый ответ до сих пор и страдал от того, что совершил хотя бы один из грехов хотя бы раз в своей карьере, и хочу, чтобы другие этого не делали =)
Патрик Хьюз
Я могу сказать, код лавины!
Брайан

Ответы:

50

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

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

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

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

Дэвид Кэри
источник
ссылка 2 и 4 напрямую ссылаются и цитируют ссылку 1. Нет ничего плохого в распространении концепции, но это немного менее актуально. Мне нравится этот термин, но, похоже, он не так сильно нагнал.
Хайлем
1
Что, если переданный код - это новый код, который совершенно изолирован от остальной части проекта? В этом случае я думаю, что один большой коммит (почти) законченного и очищенного кода лучше, чем многие маленькие коммиты, которые вынуждают людей просматривать (1) промежуточные исправления ошибок, (2) рефакторинг, такой как переименование классов и так далее, ( 3) предварительный код, который в конечном итоге будет удален. Просто мои 2 цента.
Джорджио
Это своего рода причина, по которой я против переписывания / перебазирования истории
dukeofgaming
@ Джорджио - вот для чего нужны ветки.
Брайан
@ Брайан: Да, это возможно. В этом случае у вас есть большой коммит в основной ветке, когда вы объединяете функциональность, которую вы разработали в ветке.
Джорджио
38

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

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

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

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

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

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

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

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


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

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

haylem
источник
11
Годзилла совершает! Eeeeeeeek !!!
Петер Тёрёк
@ PéterTörök: нравится. Давайте сделаем это трендом. Другие варианты: коммит кита, коммит Гаргантюана или просто BigFatCommit.
Хайлем
1
Да, «плохо» или «поздно». Если в вашей компании нет названия для него, назовите его в честь разработчика. «Эй, новый парень, не делай Джерри! Фиксируй рано и делай часто».
Чобан
Не делай Джерри, это полезный подход! Кроме того, масса-коммит может исходить от напряженных разработчиков, которые не верят и не понимают использование версий. Проверь свои знания!
Независимый
Что если чье-то имя Джерри?
Лоик Фор-Лакруа
12

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

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

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

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

JohnMcG
источник
5
Это. Что действительно важно, так это не количество измененных файлов или количество измененных строк, а масштаб изменений. Если вы можете кратко и точно описать набор изменений в коротком сообщении о фиксации, в котором ничего не пропущено, счетчик физических изменений является относительно несущественным. Не маловажно, но я предпочел бы иметь один большой коммит, который поддерживает сборку кода, а не набор коммитов, где только некоторые из них приводят к созданию дерева исходного кода (см. Изменение сигнатуры метода).
CVn
8

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

Джесси С. Слайсер
источник
+1, поскольку я не помнил этого в то время (хотя я не думаю, что это общий термин, или я не знаю об этом), но я слышал слово «кусок», используемое конкретно ртутью по отношению к расширение, позволяющее отправлять большие коммиты с разными кусками данных, но кроме этого я не думаю, что когда-либо слышал этот термин для коммитов в целом.
Хайлем
Компания, в которой я работал, когда разработчик использовал этот термин, использовала SourceGear Vault.
Джесси С. Slicer
3

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

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

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

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

Бро Кевин Д.
источник
2

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

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

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

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

linquize
источник