Отказ от ответственности: я не пользователь hg, поэтому я читал о hg, но у меня нет особого опыта его использования.
git предоставляет несколько очень мощных и гибких инструментов для управления ветвями в стиле 'очереди исправлений', поэтому для многих базовых (и даже некоторых довольно сложных) вариантов использования нативный git является достаточно мощным.
Как правило, большинство проектов поддерживают центральную стабильную главную ветвь, которая получает только новые коммиты и никогда не перематывается, поэтому фиксации в основной ветке фиксируются.
Кроме того, сопровождающий (или разработчик) может поддерживать одну или несколько текучих веток исправлений в процессе (т. Е. Коммитов), основанных на стабильной ветке.
Типичные действия по управлению исправлениями включают в себя:
перестановка очереди исправлений в последнюю стабильную ветвь - используйте git rebase,
дублирование очереди исправлений на старую ветку обслуживания - используйте git branch и git rebase,
изменение порядка исправлений в очереди - используйте git rebase --interactive (он же git rebase -i), используя текстовый редактор для изменения порядка очереди.
патчи для сдавливания - используйте git rebase -i с директивой для сквоша
Изменение патчей или сообщений о фиксации патча - используйте git rebase -i (определить тему?) С директивой редактирования.
Любое действие, которое каким-либо образом изменяет патч (то есть его содержимое, описание или происхождение), создает новый коммит с новым идентификатором фиксации для этого патча. Тот факт, что старые коммиты могут регулярно выбрасываться и заменяться до их перехода в стабильную главную ветвь, является единственным, что делает их «очередью исправлений», а не ветвью, но это соглашение проекта, а не физическое различие. в данных, которые составляют коммиты. Для мерзавцев это идентичные объекты.
Чтобы преобразовать патч в «реальный» коммит, просто переместите патч в начало очереди и объедините его с главной веткой. После перемещения патча в начало очереди, он точно такой же, как и обычный коммит, основанный на главной ветви, поэтому его слияние просто ускоряет пересылку указателя главной ветки для указания на фиксацию патча.
Публикация этого коммита как «стабильного» мастер-патча - это акт, который гласит: это коммит, который не изменится и является частью неизменной истории проекта.