Направление стрелки в книге ProGit
Почему на всех изображениях, которые показывают очередь коммитов в книгеPro Git, стрелки ведут в обратном направлении?
2 ответа
Это чтобы показать родительские отношения. В Git конкретный коммит знает о своих родителях, но не обязательно о своих потомках. (Очевидно, что информация может быть получена на основе родительских ссылок, но я не думаю, что она хранится непосредственно в объекте коммита.)
Стрелками показано направление, которому следует DAG, направленный ациклический граф, представляющий здесь историю коммитов в Git (от самых последних до самых старых).
Это представление не является "идеальным", как подробно рассказывает Эрик Синк в своей статье:
Одна из самых крутых вещей в инструментах контроля версий на основе DAG- это то, что DAG является выражением истории слияний. Мы интерпретируем стрелки в DAG для обозначения "У меня есть это".
Итак, когда приходит время выполнить слияние с 5b на ветку (a), мы можем использовать информацию в DAG, чтобы знать, что 3b и 2b уже выполнены
В той же статье подробно описывается предел этого представления:
Но DAG- это всего лишь одна из реализаций истории слияний, и она определенно не идеальна.
Стрелка в DAG контроля версий переходит от дочернего к родительскому. Это говорит нам о том, что дочерний элемент содержит все изменения родительского элемента. И его бабушка и дедушка. И его прадедушка. И так далее.
Но что, если это не так?
Рассмотрим следующую картину:
Я хочу создать набор изменений 4.
Я хочу начать с набора изменений 1, а затем я хочу применить изменения из набора изменений 3, но НЕ вещи из набора изменений 2.
Эту операцию иногда называют "вишнёвка". Я не хочу объединять все изменения из одной ветви в другую. Я просто хочу взять один набор изменений (или одну часть набора изменений) и применить его как патч к другому месту.Как мне представить это в DAG?
Я не могу
- Я мог нарисовать стрелку от 4 до 3 (показано выше красным). Это будет правильно сказать, что 4 содержит изменения в 3, но это будет НЕПРАВИЛЬНО утверждать, что 4 содержит изменения в 2.
- ИЛИ я не мог нарисовать стрелку. По сути, моя история слияния просто не зафиксировала бы тот факт, что 4 - это действительно 3, преобразованные в патч и примененные к 1.
В любом случае, что-то плохое случится в следующий раз, когда я сливаюсь из одной ветви в другую:
- Если я нарисую эту лежачую стрелку, мне не дадут возможности применить changeset 2, потому что история слияний считает, что я уже сделал это.
- Если я не нарисую стрелку, инструмент будет ожидать, что я буду иметь дело с набором изменений 3, потому что в истории слияний нет записи о том, что я это уже сделал.
Ни одна из этих проблем не является настолько катастрофической, чтобы делать вечерние новости, но все же.
Вот почему перебазирование никогда не бывает далеко после операции "выбора вишни", чтобы получить более классический DAG.