Распределенное управление источниками и непрерывная интеграция не являются взаимоисключающими понятиями. На самом деле они играют очень хорошо вместе.
Несмотря на то, что DVCS по своей природе распределены, у вас все равно будет центральный репозиторий, представляющий традиционный «ствол», обнаруженный в централизованных системах версий. Вы не должны изменять свою модель разработки с точки зрения того, когда и какие изменения вы «публикуете» в своем центральном хранилище. Поскольку DVCS не заставляет вас настаивать на изменениях, вы должны быть очень дисциплинированными в этом отношении.
С другой стороны, DVCS позволяет разработчикам делать меньшие, инкрементные коммиты в своих частных ветвях. Этим изменениям не только легче следовать, но и их легче объединить в конце. Наличие локальных коммитов особенно полезно при добавлении функции или экспериментальных изменений. Или когда вам нужно прервать работу над функцией A, чтобы исправить очень важную ошибку B.
Индивидуальный разработчик решает, что будет опубликовано и когда. Как всегда, с дополнительной силой приходит дополнительная ответственность.
Вы должны публиковать / публиковать изменения, когда они будут готовы. Например я хочу переименовать класс. Это коснется 50+ файлов, хотя всего несколько строк. Я делаю переименование с помощью инструмента рефакторинга.
В централизованной системе мне теперь нужно было бы решить, стоит ли это делать самому по себе, или это часть большей работы, над которой я сейчас работаю. Исходя из опыта, люди обычно выбирают второй вариант, потому что вы не уверены, хотите ли вы, чтобы это было частью постоянной истории.
В распределенной системе я могу зафиксировать изменение локально, у меня есть четкая история, разделяющая механические (рефакторинг) и функциональные изменения кода. На данный момент я ни на кого не влияю. Я мог бы легко пересмотреть это решение позже, прежде чем я, наконец, вытолкну свои изменения. Это будет чистый коммит сам по себе.
Проблема в этом примере заключается в следующей ситуации: представьте, что я переименую этот класс в моей локальной ветке или в моем «отложенном коммите». Тем временем кто-то передает новый код транку, который использует класс, который я только что переименовал. Будет трудно слить мое переименование.
Конечно, вы могли только что опубликовать это изменение в тот момент, когда вы это сделали. В обеих системах. Ответственность все та же. Но так как DVCS поощряет вас иметь меньшие, постепенные коммиты, объединение будет легче. Обе системы могли бы предоставить вам одну и ту же «стратегию выхода» из этой ситуации, если вы опубликовали свои изменения раньше.