В двух последних выпусках «Радио Т» ведущие пытались обсудить ГИТ.
Евгений (@Umputun) поинтересовался, зачем нужен rebase и очень удивился, когда я спросил, редактирует ли он коммиты.
На мой взгляд, чтобы понять GIT, достаточно углубиться в процесс разработки ядра Linux, поскольку оно создано именно для этой цели.
Посмотрим, как изменения попадают в основной репозиторий.
Разработчик клонирует git и приступает к разработке нового функционала.
В процессе разработки он пишет код, тестирует, находит ошибки и исправляет их.
Вероятно, делает определенное количество коммитов.
Когда фича готова, вы не можете просто отправить все эти коммиты в виде патчей, как не можете отправить все это в виде одного патча.
Следующая цель разработчика — разложить все изменения таким образом, чтобы это было понятно сопровождающему и другим членам команды.
В этом процессе есть несколько правил: каждый патч содержит только одно логическое изменение; каждый патч не должен быть деструктивным; Сообщение о коммите должно описывать изменения как можно подробнее.
Эта двойная работа имеет свою мотивацию.
Обзор патчей — не самое увлекательное и интересное занятие, поэтому каждый должен постараться максимально упростить этот процесс.
Мейнтейнеру, как и остальной команде, не интересно наблюдать за тем, как ваши мысли кружатся в поисках правильного решения.
Им просто нужно прочитать сообщение коммита, в котором будет описано, почему был выбран именно этот подход. Еще меньший интерес представляют ошибки, допущенные вами во время разработки.
Чаще всего я создаю новую ветку, откатываю все коммиты (git reset) и начинаю ломать с помощью git commit --interactive. Эта команда позволяет вам выбрать, какие изменения будут переданы в какой коммит. Когда все будет готово, патчи можно сгенерировать с помощью команды git format-patch и отправить с помощью git send-email. Хорошо, если патчи были приняты сразу, но иногда кто-то находит в них ошибки и просит добавить комментарии или еще что-то исправить.
В этом случае нам понадобится git rebase --interactive, который позволит нам изменить порядок коммитов, объединить два или более коммита или остановиться на любом коммите, чтобы отредактировать его.
После исправления всех недочетов мы генерируем и отправляем патчи второй раз и так до тех пор, пока они не будут приняты.
Кстати, прежде чем отправлять патчи в рассылку, вам необходимо обновить свой репозиторий, и таким образом, чтобы все наши изменения остались сверху, это называется rebase. Если сопровождающий принимает исправления, он фиксирует их в своем репозитории.
Когда появляется следующее окно слияния, оно отправляет запрос на включение вышестоящему сопровождающему.
В идеале вы могли бы переносить каждое новое изменение индивидуально и иметь линейную историю.
Мы живем в реальном мире, где изменения могут конфликтовать друг с другом, и нет времени объединять каждое отдельное изменение.
Поэтому на помощь приходит git pull, в котором все изменения фиксируются одним куском, а конфликты фиксируются один раз, хотя в истории (git log) все выглядит линейно.
В подкасте также упоминался git bisect — инструмент для двоичного поиска коммита, который все сломал.
Допустим, вы знаете коммиты, где ошибки не было, а где ошибка уже есть.
Цель — найти коммит, в котором возникла эта ошибка, за минимальное количество шагов.
Откатываемся к коммиту, который находится ровно посередине.
Если на этом этапе ошибки нет, то проблемный коммит находится справа, в противном случае — слева.
Повторяем, пока не найдем.
Особенность git bisect в том, что он умеет корректно обрабатывать нелинейные куски истории, о которых мы говорили выше.
Теги: #git #ядро Linux #rebase #pull request #patch #merge #Umputun #Radio-T #bisect #open source #git
-
Сбор И Анализ Логов Для Новичков
19 Oct, 24 -
Жестокость Формулы Циолковского
19 Oct, 24 -
Развитие Бизнеса В Стартапах
19 Oct, 24 -
Наизнанку
19 Oct, 24 -
Android Ndk: Opensl Es
19 Oct, 24
