В программном обеспечении для контроля версий набор изменений (также известный как фиксация [1] и ревизия [2] [3] ) представляет собой набор изменений, упакованных вместе, вместе с метаинформацией об изменениях. Набор изменений описывает точные различия между двумя последовательными версиями в репозитории изменений системы контроля версий. Наборы изменений обычно рассматриваются системами контроля версий как атомарная единица, неделимый набор. Это одна из моделей синхронизации . [4] [5]
В системе контроля версий Git набор изменений называется фиксацией [1], [6] не следует путать с операцией фиксации , которая используется для фиксации набора изменений (или, в случае Git, технически снимка [1] ) в репозитории .
Другие системы контроля версий также используют другие названия для обозначения наборов изменений, например , Darcs называет их «патчами» [7] , а Pijul называет их «изменениями» [8] .
Системы контроля версий прикрепляют метаданные к наборам изменений. Типичные метаданные включают описание, предоставленное программистом («сообщение о коммите» на жаргоне Git), имя автора, дату коммита и т. д. [9]
Уникальные идентификаторы являются важной частью метаданных, которые системы контроля версий прикрепляют к наборам изменений. Централизованные системы контроля версий, такие как Subversion и CVS, просто используют инкрементные числа в качестве идентификаторов. [10] [11] Распределенные системы контроля версий , такие как Git , генерируют уникальный идентификатор, применяя криптографическую хэш-функцию к набору изменений. [12]
Поскольку системы контроля версий работают с наборами изменений как с атомарными единицами, а коммуникация внутри групп разработчиков повышает производительность, существуют определенные рекомендации, которым нужно следовать при создании наборов изменений. Здесь упомянуты только 2 наиболее важных: атомарность содержимого набора изменений и описания наборов изменений.
Содержимое набора изменений должно включать только одну задачу или исправление и содержать только тот код, который работает и не нарушает заведомо существующую функциональность. [13]
Описания изменений должны быть краткими, отражающими причину внесения изменений, эффект или цель изменений, а также описывающими неочевидные аспекты того, как работает изменение. [14]
Напишите минимально возможный объем кода для решения проблемы. После выявления проблемы или улучшения лучший способ попробовать что-то новое и непроверенное — разделить обновление на небольшие партии ценности, которые можно легко и быстро протестировать с конечным пользователем, чтобы доказать обоснованность предлагаемого решения и откатить его в случае, если оно не работает, не делая устаревшей всю новую функциональность. ... В связи с внесением небольших изменений атомарные коммиты представляют собой единую единицу работы, включающую только одну задачу или одно исправление (например, обновление, исправление ошибки, рефакторинг). Атомарные коммиты ускоряют проверку кода и упрощают откат, поскольку их можно применять или откатывать без каких-либо непреднамеренных побочных эффектов. Цель атомарных коммитов — не создание сотен коммитов, а группировка коммитов по контексту. Например, если разработчику необходимо провести рефакторинг кода и добавить новую функцию, он создаст два отдельных коммита, а не один монолитный коммит, включающий изменения с разными целями.
Отслеживание изменений ... обеспечивает анализ предыдущих изменений, а также целостное представление траектории набора данных. История документа ... дает информацию о
(sic)
цели внесенных изменений.