Как организовать ревизии в иерархиях?

Question

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

Я приведу тривиальный пример из реальной практики из моей практики, который приведет меня к этому вопросу.

Предположим, я хочу реорганизовать метод функции / класса. Я создаю заявку и называю ее, скажем, « Метод рефакторинга ClassName.method_name () ». Изучив код method_name () , я разделил процесс рефакторинга на подзадачи. Для простоты, давайте рассмотрим, что мне нужно переименовать две переменные с разными значениями в коде, поэтому мне нужно сделать это в два отдельных атомарных шага. Я переименовываю переменную, сохраняю изменения и фиксирую сообщение « переименована переменная foo в ClassName.method_name () » (потому что фиксация на ранней стадии и фиксация часто - это хорошо). Я повторяю для второй переменной: « переименованная переменная бара в ClassName.method_name () ».

Теперь у меня есть один тикет в трекере проблем с именем " Метод рефакторинга ClassName.method_name () " и две ревизии в управлении версиями:

• "переименованная переменная foo в ClassName.method_name ()"
• "Переименованная переменная бара в ClassName.method_name ()"

Где связь между вопросом и этими двумя изменениями? Я потерян!

Моя цель - создать логическую иерархию, подобную этой:

• "Метод рефакторинга ClassName.method_name ()"
  • "Переименованная переменная foo в ClassName.method_name ()"
  • "Переименованная переменная бара в ClassName.method_name ()"

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

Это имело бы смысл, я фанат использования планировщиков и организации данных в иерархии с использованием деревьев.

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

Answer 1

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

• Создайте ветку из вашего ствола с именем «refactor method».
• Создайте ветку из вашей ветки «refactor method» с именем «rename»foo. "
• Выполняйте всю работу по переименованию foo, фиксируя в ответ ветку" rename foo ".
• Объедините" rename foo "обратно в" метод рефакторинга ".
• Создайте ветку из вашей ветки «refactor method» с именем «rename bar».
• Выполняйте всю свою работу по переименованию bar, фиксируя в ветке «rename bar» по мере продвижения.
• Слияние «переименовать бар» обратно в «метод рефакторинга».
• Слияние «метод рефакторинга» обратно в ваш ствол.

Отображение ветви ствола с помощью графического инструмента покажетпросто «метод рефакторинга» со знаком плюс или что-то для его расширения, вроде как:

.Нажав на знак плюс, вы увидите «переименовать foo» и «переименовать бар».Повторное нажатие покажет все отдельные шаги.Кроме того, работа может происходить параллельно, люди регистрируются в другом порядке, чем они, и вы все равно получите иерархическую историю.На моем графике вы можете видеть, что Арнольд проверял свое исправление ошибки после того, как Эми ответила за ее изменения, но история все еще работает.