От переводчика: в этой статье не описаны команды git, предполагается, что вы с ним уже знакомы.
Это описывает, на мой взгляд, вполне разумный подход к сохранению чистоты и порядка общественной истории.
Если вы не понимаете, что побудило сделать git таким, какой он есть, то вас ждут несчастья.
Используя множество флагов (--flag), вы можете заставить git работать так, как вы думаете, вместо того, чтобы работать так, как git хочет. Это как забивать гвозди отверткой.
Работа выполняется, но хуже, медленнее, и отвертка повреждается.
Давайте посмотрим, как разваливается традиционный подход к разработке с помощью git. Отпочковываем ветку от master, работаем, сливаем обратно, когда закончим.
В большинстве случаев это работает так, как ожидалось, потому что мастер меняется после ветвления.
(Это значит, что ваши коллеги обязуются освоить – прим.
переводчика.
) .
Однажды вы объединяете ветку функций с основной, но мастер не изменился.
Вместо коммита слияния git просто перемещает главный указатель на последний коммит, происходит перемотка вперед. Чтобы объяснить механизм быстрой перемотки вперед, я позаимствовал картинку из известной статьи.
Примечание переводчика 
К сожалению, ваша ветка функций содержала промежуточные коммиты — частые коммиты, которые резервируют работу, но фиксируют код в поврежденном состоянии.
Теперь эти коммиты неотличимы от стабильных коммитов в мастере.
Вы можете легко снова попасть в такую катастрофу.
Итак, вы добавляете новое правило: «Используйте --no-ff при объединении ветвей функций».
Это решит проблему, и вы двинетесь дальше.
И вот однажды вы обнаруживаете критическую ошибку в продакшене и вам нужно отследить момент, когда она появилась.
ты бежишь разделить пополам , но вы постоянно получаете промежуточные коммиты.
Вы сдаетесь и ищете руками.
Вы локализуете ошибку вплоть до файла.
Запустите функцию «Вина», чтобы увидеть изменения за последние 48 часов.
Вы знаете, что это невозможно, но вина сообщает, что файл не менялся уже несколько недель.
Оказывается, вина сообщает о времени исходного коммита, а не о времени слияния ветки.
(логично, т.к.
merge commit пуст — прим.
переводчика) .
Ваш первый промежуточный коммит изменил этот файл несколько недель назад, но это изменение было объединено только сегодня.
Неработающий костыль, сломанная биссектриса и невнятное обвинение — симптомы забивания гвоздей отверткой.
Переосмысление контроля версий
Контроль версий необходим для двух вещей.Первый предназначен для помощи в написании кода.
Возникает необходимость синхронизировать правки с вашей командой и регулярно делать резервные копии своей работы.
Вторая причина управление конфигурацией .
Включает параллельное управление разработкой.
Например, работать над следующей версией выпуска и параллельно исправлять ошибки существующей производственной версии.
Управление конфигурацией означает возможность узнать, когда что-то изменилось.
Бесценный инструмент для диагностики ошибок.
Традиционно эти две причины вступают в противоречие.
При разработке какого-то функционала вам потребуются регулярные промежуточные коммиты.
Однако эти коммиты обычно нарушают сборку.
В идеальном мире каждое изменение истории версий является кратким и стабильным.
Нет никаких промежуточных коммитов, которые создают помехи.
Здесь нет гигантских коммитов на 10 000 строк.
Аккуратная история позволяет откатывать изменения или перемещать их между ветками с помощью выбор вишни .
Аккуратную историю легче изучать и анализировать.
Однако поддержание чистоты истории означает, что все правки безупречны.
Итак, какой подход вы выберете? Частые коммиты или аккуратная история? Если вы вместе работаете над стартапом, который готовится к запуску, аккуратная история не очень убедительна.
Вы можете зафиксировать все для мастер-класса и выпускать релизы, когда захотите.
По мере увеличения масштабов изменений, будь то рост команды разработчиков или размер пользовательской базы, вам потребуются инструменты для поддержания порядка.
Это включает в себя автоматическое тестирование, проверку кода и аккуратную историю.
Функциональные ветки кажутся хорошим компромиссом.
Они решают простые задачи параллельной разработки.
Вы думаете об интеграции в наименее важный момент, когда пишете код, но на какое-то время это вам поможет. Когда ваш проект станет достаточно большим, простой подход ветвления/фиксации/слияния развалится.
Время использования скотча прошло.
Вам нужна аккуратная история изменений.
Git является революционным, потому что он дает вам лучшее из обоих миров.
Вы можете часто делать коммиты во время разработки и очищать историю по завершении.
Если это ваш подход, то значения по умолчанию git имеют больше смысла.
(имеется в виду перемотка вперед по умолчанию при слиянии ветвей - примечание переводчика) .
Последовательность действий
Подумайте об филиалах с точки зрения двух категорий: государственные филиалы и частные филиалы.Публичные темы — это официальная история проекта.
Коммит в публичную ветку должен быть кратким, атомарным и хорошо описанным.
Оно должно быть линейным.
Оно должно быть неизменным.
Публичные ветки — это master и Release. Частная тема для себя.
Это ваш черновик при решении проблемы.
Наиболее безопасно хранить частные ветки локально.
Если вам нужно, например, ускорить синхронизацию рабочего и домашнего компьютеров, сообщите своим коллегам, что филиал принадлежит вам и им не следует на него полагаться.
Не следует объединять частную ветку с публичной с помощью простейшего слияния.
Сначала очистите свою ветку с помощью таких инструментов, как сброс, перебазирование, слияние --squash и коммит --amend. Думайте о себе как о писателе, а о своих коммитах — как о главах книги.
Писатели не публикуют черновики.
Майкл Крайтон сказал: «Великие книги не пишутся, их переписывают».
Если вы пришли из других ВКС, изменение истории покажется вам табу.
Вы предполагаете, что каждый коммит высечен в камне.
Следуя этой логике, нам нужно убрать «отмену» из текстовых редакторов.
Прагматики заботятся об изменениях только до тех пор, пока они не начнут раздражать.
Что касается управления конфигурацией, нас интересуют только глобальные изменения.
Промежуточные коммиты — это просто легкий буфер, который можно отменить.
Если рассматривать историю как нечто незапятнанное, то ускоренное слияние не только безопасно, но и предпочтительно.
Это сохраняет историю линейной и ее легче отслеживать.
Единственный оставшийся аргумент в пользу --no-ff — это документация.
Вы можете использовать коммиты слияния для связи с последней версией производственного кода.
Это антипаттерн.
Используйте теги.
Рекомендации и примеры
Я использую три простых подхода в зависимости от размера изменения, того, как долго я над ним работаю и насколько далеко ветка отклонилась от намеченного пути.
Быстрое редактирование
Большую часть времени очистка представляет собой просто сквош-фиксацию.Допустим, я создал ветку функций и в течение часа сделал несколько промежуточных коммитов.
Закончив, вместо простого слияния я делаю следующее:git checkout -b private_feature_branch touch file1.txt git add file1.txt git commit -am "WIP"
git checkout master
git merge --squash private_feature_branch
git commit -vЗатем я трачу минуту на написание более подробного комментария к коммиту.
Больше редактирования
Иногда реализация какой-либо функции перерастает в многодневный проект с множеством мелких коммитов.Я решил, что мой монтаж следует разделить на более мелкие части, так что сквош — слишком грубый инструмент. (Как правило, я спрашиваю себя: «Легко ли будет сделать ревью кодаЭ») Если бы мои промежуточные коммиты были логичным шагом вперед, я мог бы использовать перебазировать интерактивно.
Интерактивный режим — это мощный инструмент. Вы можете использовать его для редактирования старых коммитов, разделения или систематизации их и, в данном случае, объединения нескольких.
В функциональной ветке: git rebase --interactive master
Откроется редактор со списком коммитов.
Каждая строка содержит: команду, которая будет выполнена, хэш SHA1 и комментарий к фиксации.
Ниже приведен список возможных команд. По умолчанию каждый коммит имеет значение «pick», что означает «не изменять коммит».
pick ccd6e62 Work on back button
pick 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar
Я меняю команду на «squash», которая объединяет текущий коммит с предыдущим.
pick ccd6e62 Work on back button
squash 1c83feb Bug fixes
pick f9d0c33 Start work on toolbar
Я сохраняю, теперь другой редактор запрашивает комментарий к объединенному коммиту.
Все готово.
Неудачные ветки
Возможно, фича-ветка существовала уже давно и в нее были объединены другие ветки, чтобы сохранить ее актуальность.История сложная и запутанная.
Самое простое решение — взять приблизительный дифф и создать новую ветку.
git checkout master
git checkout -b cleaned_up_branch
git merge --squash private_feature_branch
git reset
Теперь рабочий каталог полон моих правок и никакого наследия предыдущей ветки.
Теперь берем и вручную добавляем и фиксируем правки.
Давайте подведем итоги
Если у вас проблемы с настройками по умолчанию в git, спросите себя, почему.Считайте публичную историю неизменной, атомарной и легко отслеживаемой.
Считайте частную историю изменчивой и гибкой.
Процедура следующая:
Создайте частную ветку из публичной ветки.Методично поручите работу этой частной ветке.
Как только код достиг совершенства, мы приводим историю в порядок.
Сливаем заказанную ветку обратно в публичную.
Теги: #git #контроль версий #git рабочий процесс #разработка веб-сайтов #git #системы контроля версий
-
В 1С Нет Ux/Ui Проектирования
19 Oct, 24 -
Леденец Для Всей Z-Серии!
19 Oct, 24
