Гайд по Git : Часть 2 : Ветки и слияние веток
В этой статье разбираемся с понятием веток в git. Как смержить одну ветку в другую, и чем отличается Merge от Rebase.
Почти каждая система контроля версий (СКВ) в какой-то форме поддерживает ветвление. Используя ветвление, вы отклоняетесь от основной линии разработки и продолжаете работу независимо от неё, не вмешиваясь в основную линию. Во многих СКВ создание веток — это очень затратный процесс, часто требующий создания новой копии каталога с исходным кодом, что может занять много времени для большого проекта.
Ветки в Git, как и коммиты, невероятно легковесны. Ветка в Git — это простой перемещаемый указатель и ничего более. Вот почему многие фанаты Git повторяют мантру:
делай ветки сразу, делай ветки часто
Команда git branch позволяет не только создавать ветки, но и просматривать существующие. Ветка, на которой вы находитесь помечается звездочкой.
Сообщим Git, что хотим переключиться на другую ветку:
Чтобы понять, почему мы это называем ветками, переключимся на ветку main и сделаем еще один коммит там.
Напоследок вот совет, как создать новую ветку и переключиться на неё с помощью одной команды:
Merge
Мы уже знаем, как создавать ветки и коммитить наши изменения. Теперь надо понять, как объединять изменения из двух разных веток, после того как вы выполнили свою задачу в отдельной ветке.
Слияния создают особый вид коммита, который имеет сразу двух родителей. Коммит с двумя родителями обычно означает, что мы хотим объединить изменения из одного коммита с другим коммитом и всеми их родительскими коммитами.
Втащим все изменения из ветки newImage в ветку main :
А также посмотрим log, убедимся что появился новый коммит:
Rebase
Несмотря на то, что это звучит достаточно непонятно, преимущество rebase в том, что c его помощью можно делать чистые и красивые линейные последовательности коммитов. История коммитов будет чище, если вы применяете rebase.
Посмотрим, как это работает:
Git дописал копию коммита C7 за коммитом C6 и перенес туда указатель
Удалим ветку bugFix и снова проверим log:
Напоследок вот вам шпаргалка по отличию Merge от Rebase:
Сравнение Merge и Rebase
Заключение
Мы разобрались с ветками в Git и их слиянием. В идельном проекте все ветки стремятся влиться в одну.
Не забывайте создавать новые ветки от основной ветки разработки для каждой самостоятельной задачи.
Git. Урок 3.
Ветвление. Создание, переключение и удаление веток. Команды: branch, checkout, status, log, diff.
1. Что такое ветка.
2. Зачем нужны ветки.
3. Создание новых веток.
4. Просмотр списка веток.
5. Переключение между ветками.
6. Просмотр состояния ветки. Команды: git status, git log, git diff.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
6.3. Просмотр различий между коммитами. Команда git diff.
7. Удаление веток.
Дадим два определения ветки: на логическом и физическом уровнях.
1. Логический уровень.
С точки зрения логики, ветка – это последовательность коммитов. Чтобы проще было понять, что такое ветка, рассматривайте ее как некоторую временную шкалу. Коммиты в ней – снимки интересных моментов, идущие друг за другом в хронологической последовательности. Рисунок ниже поможет вам в интуитивном представлении.
2. Физический уровень
На физическом уровне, то есть с точки зрения внутренней реализации Git, ветка – это ссылка на последний коммит в этой ветке. Картинка ниже поможет вам понять, что к чему.
Преимущество веток в их независимости. Вы можете вносить изменения в файлы в одной ветке, например, пробовать новую функцию, и они никак не скажутся на файлах в другой ветке. Изначально в репозитории одна ветка, но позже мы рассмотрим, как создавать другие.
На самом деле, вначале, когда мы делаем свой первый коммит, Git автоматически создает основную ветку. Вы можете помнить, что ее имя по умолчанию «main» мы задавали в настройках Git в предыдущем уроке. Каждый раз, когда мы создаем новый коммит, Git автоматически перемещает указатель main на последний коммит. Тем не менее, в следующем уроке мы узнаем, как перемещать указатель ветки между коммитами самостоятельно.
Пока мы разбирались, что такое ветка, у вас мог возникнуть вопрос: зачем нужны такие сложности, ведь можно просто делать коммиты и откатывать изменения, когда нужно.
Дело в том, что Git – универсальная система контроля версий: она подходит и большим командам крупных корпораций, и индивидуальным разработчикам для их личных проектов.
Если вы работаете один – скорее всего вы будете редко использовать ветки, но если вы работаете в большой компании, без веток вам не обойтись.
Итак, чаще всего ветки используются в следующих случаях.
Способ 1. Команды git branch + git checkout
Команда git branch
На самом деле, git branch – очень мощная команда, которая умеет много всего. Сейчас мы рассматриваем ее как инструмент для создания веток. Ниже мы рассмотрим еще некоторые способы ее применения.
Команда git checkout
40 шестнадцатеричных цифр в файле выше и есть хэш последнего коммита, на который указывает новосозданная ветка.
С помощью команд git branch и git checkout вы можете создать неограниченное количество веток и переключаться между ними по мере необходимости. Обычно если ветка вам больше не нужна, ее сливают с основной и удаляют. Тема слияния веток заслуживает отдельного урока, поэтому про это мы поговорим в следующий раз, а удаление веток рассмотрим чуть ниже.
Команда git branch
# Теперь выведем только локальные ветки
$ git branch
* develop
feature
main
Теперь, когда мы поняли, как можно узнать имена веток в репозитории, давайте научимся переключаться между ними.
Команда git checkout
Этот маленький фокус позволит вам сэкономить время, особенно, если вы часто переключаетесь между ветками.
Шаг 1. Проверка существования ветки
Нужен этот этап, чтобы случайно не переключиться на ветку, которой не существует. Чтобы понять, как происходит этот процесс, нужно сделать небольшое отступление и рассказать, как вообще Git хранит информацию о существующих ветках.
Шаг 2. Переключение HEAD на нужную ветку
Шаг 3. Изменение рабочей копии
У внимательного читателя мог возникнуть вопрос: почему файлы в рабочей копии подгружаются именно из последнего коммита ветки? Что если до переключения с данной ветки, в ней были какие-то изменения, еще не добавленные в коммит? Что с ними будет? Ответ довольно прост. Согласно трем шагам, указанным выше, Git просто проигнорирует все такие файлы. То есть они останутся в вашей рабочей копии в том же состоянии, в котором и были до этого. Как правило, такое поведение очень неудобно, поскольку позволяет легко запутаться в структуре собственного проекта. Представьте: у вас два параллельных релиза, а вы, переключаясь между ветками, случайно занесли файлы одного релиза в ветку другого.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
Команда git log
-p
Показывает изменения, сделанные в данном коммите.
—graph
Рисует ASCII-граф взаимосвязи коммитов.
—all
Выводит историю всех имеющихся коммитов на всех ветках.
adding complex algebra project
commit 603def20e5da2d512da2852011eb5be3fa156940 (origin/main, origin/HEAD)
Author: smartiqa
Date: Fri Dec 4 02:00:41 2020 +0300
В описании команды git log выше сказано, что в зависимости от ситуации, она может вывести полную историю репозитория, или же только историю некоторых коммитов. Давайте разбираться, как работает Git при выводе истории.
Общее правило, которым руководствуется Git при выводе истории, такое: иди по предкам коммитов, пока они не закончатся. Иногда это бывает удобно, иногда – нет.
Давайте разберемся, что делать, если мы хотим просмотреть историю коммитов только внутри какой-то конкретной ветки. То есть историю от момента создания ветки, до последнего коммита в ней. В этом случае нужно сделать следующее:
Основы использования бранчинга для параллельной разработки
Как справедливо заметил Fred Brooks, серебряной пули, способной поразить зверя разработки программного обеспечения, не существует. Пока возникают новые требования, идеи и находятся новые баги, программы живут и изменяются. Путь, который проходит код от версии к версии, может быть крайне сложен и извилист. К его созданию причастно много людей: разработчики, тестировщики, бизнес-аналитики, заказчики и т.п. Несмотря на то, что существует много разных видов разработки – аутсорсинг, продуктовая разработка, open-source и т.п., проблемы, стоящие перед командой, остаются примерно одинаковыми. Программное обеспечение – вещь сложная, потребитель хочет получить его как можно быстрее (и дешевле). Качество при этом должно быть приемлемым. Перед командой разработки стоит серьезная задача – наладить эффективное взаимодействие. Одним из самых главных средств коллаборации внутри команды разработчиков является сам код, который они пишут.
В данный момент на рынке получают широкое распространение распределенные системы управления версиями – DVCS. Однако, львиную долю рынка удерживают традиционные и более простые в использовании централизованные системы, такие, как, например, SVN. Система управления версиями, а вернее, ее грамотное использование, играет ключевую роль в обеспечении эффективного взаимодействия. Вспомните, как давно вы читали книгу про свою VCS? Команде, в которой нет людей, способных выстроить грамотное взаимодействие через VCS, исходя из потребностей проекта, не позавидуешь.
Давайте представим себе идеальное управление релизами. Релиз-менеджер может оценить состояние кода и выбрать реализованный функционал для включения в релиз. Этот функционал должен быть готов и протестирован. Также релиз-менеджер может включить исправления дефектов с прошлого релиза. Неготовый, нестабильный и непротестированный функционал в релиз попасть не должен. Если от QA-специалистов поступает информация о нестабильности того или иного функционала, релиз-менеджер должен иметь возможность убрать его из релиза. Часто возникает потребность в переносе исправлений дефектов на уже работающую у конечного пользователя версию, потому что он по каким-то причинам не может перейти на новую.
Если немного сменить точку зрения и посмотреть на процесс работы над кодом со стороны разработчика, то он должен сидеть в своей песочнице и не подвергаться влиянию дестабилизирующих коммитов со стороны коллег. В идеале, разработчики должны обмениваться только законченными и стабильными наборами изменений. Так ведь проще понять что было сделано, правда? Тем не менее, коммиты не должны диктовать разработчику стиль его работы, и он всегда должен иметь возможность вкомитить только частично выполненный функционал.
Описанные выше проблемы имеют несколько решений. Одно из них – правильный выбор и грамотное использование проектной системы управления версиями. Еще одно – понимание возможных стратегий бранчинга (ветвления) и цены, которую придется заплатить за всю эту роскошь.
Отступление про версионность кода
Как правило, системы управления версиями хранят историю изменений в виде линии (централизованные) или графа (распределенные). Ветка (бранч) – это просто линия разработки кода, которая имеет общую историю с другими ветками и существует параллельно с ними. Jeff Atwood в своем блоге сравнивает ветки с параллельными вселенными. В такой вселенной в какой-то момент история пошла по-другому относительно других. Это дает нам безграничные возможности, которые уравновешиваются безграничной сложностью наших вселенных.
Как правило, одна из наших историй является основной и носит гордое имя trunk или mainline. По аналогии с деревом, от нее отходят другие ветки. В эту ветку рано или поздно попадает готовый (или не совсем) функционал и исправления ошибок.
Branch per release
Рассмотрим первый из этих случаев, когда отдельная ветка создается под каждый релиз. Это делается для того, чтобы исправлять дефекты, найденные после выпуска релиза или во время его тестирования. Этот процесс обычно называется стабилизацией. При этом сами исправления (багфиксы) не остаются только в релизных ветках, а переносятся в mainline (если история релиза и mainline не слишком разошлись), делая ее стабильнее. Код в релизной ветке изолирован от дестабилизирующего влияния разработки нового функционала и при этом не блокирует ее. Сама по себе релизная ветка предоставляет легкую возможность осуществлять поддержку релизной версии. Когда прекращается поддержка релиза, его ветка замораживается. А пока идет проект, mainline продолжает свое развитие, являясь точкой, в которой накапливается новый функционал для следующих релизов.
Таким же образом можно осуществлять поддержку релизов для разных заказчиков, выделяя по ветке для каждого, если по каким-то причинам им нельзя поставить одну и ту же версию. Хочу отметить, что поддержка разных вариаций одной и той же версии — задача трудоемкая и ее следует избегать по мере возможности.
Branch per feature
Следующий случай — это выделение отдельной ветки для разработки нового функционала. Как правило, это одна логически законченная функциональная область, или просто feature. Новый функционал объединяется с основной веткой только после полного завершения, что позволяет избежать негативного влияния незавершенной работы на другие линии разработки. После того как новый функционал готов и объединен с основной веткой, другие ветки разработки должны быть интегрированы с mainline, чтобы не накапливался эффект отложенной интеграции. Использование веток для релизов и разработки позволяет нам не ждать, пока окончится тестирование и стабилизация релиза, а сразу приступить к разработке функционала для следующего.
Также можно создавать sub-branches для релизных и девелоперских веток, если нужны еще уровни изоляции. Во всех случаях создания новой ветки следует понимать цену ее поддержки, о чем будет упомянуто немного позже.
Интеграция между ветками
Основная ветка (mainline, trunk) является главным местом интеграции при помощи кода. Так или иначе, все изменения, сделанные разработчиками, попадают сюда. Тем не менее, она не должна превращаться в свалку нестабильного и незаконченного кода. Именно поэтому разработку новых фич рекомендуется проводить в отдельной ветке, интегрировать с основной, тестировать и только потом объединять изменения. Иными словами, mainline должна содержать достаточно законченный код, который может послужить основой для стабилизационной релизной ветки. Также, багфиксы из релизных веток, пройдя через mainline, попадают в ветки для разработки, таким образом, работа ведется над более стабильным кодом. Хорошим правилом является то, что мы не должны отдавать нестабильные изменения в другие ветки и что мы должны принимать стабильные изменения из других веток.
Рассмотрим ситуацию, отображенную на картинке:
Интеграция через Mainline не является единственным способом интегрироваться – возможна интеграция напрямую между ветками. Martin Fowler называет такой способ Promiscuous Integration. Для такого метода интеграции очень важна коммуникация внутри проектной команды.
У такой модели есть градация стабильности, где самыми стабильными являются релизные ветки, менее стабильной является mainline, и самыми нестабильными являются ветки для разработки. Как правило, на диаграммах самые стабильные ветки отображаются выше всех, а нестабильные – ниже всех.
Накладные расходы, связанные с использованием бранчинга
С бранчингом связаны следующие издержки:
Типы зависимостей между ветками и способы их решения
Между ветками могут возникать следующие зависимости:
Существует несколько типовых решений для работы с таким зависимостями:
Важно понимать, что грамотный модульный дизайн приложения может сильно уменьшить или свести на нет необходимость использования бранчинга и является мощным инструментом для решения проблем, связанных с параллельной разработкой.
Бранчинг позволяет нам одновременно вести два вида разработки: стабилизацию и реализацию нового функционала. Однако, это не единственный способ его применения. Например, отдельные ветки могут выделяться для разделения итераций или для изоляции разных команд.
Правильный выбор стратегии бранчинга зависит от потребностей проекта и возможностей/ограничений используемой системы управления версиями (которую, впрочем, никто не запрещает сменить). Ограничения реального мира, которые накладываются на процесс, часто невозможно решить без возможности осуществления паралелльной разработки. Тем не менее, неграмотное понимание и использование бранчинга часто приводит к анти-паттернам, которые и завершают этот материал.
Бранч-стратегии при разработке в Git
Если каждый член команды будет создавать ветки в Git так, как хочет, это обязательно приведет к хаосу и несогласованности. Чтобы избежать этого, лучше сформулировать и принять соответствующую бранч-стратегию — так вы сможете больше времени уделять разработке, а не управлению версиями. Нужно принять тот факт, что стратегия ветвления — важный рабочий инструмент.
Три подхода
Вы можете использовать одну из этих популярных методик или же взять их как основу для создания своей.
GitHub Flow. Стратегией пользуются в команде сервиса GitHub. Главные требования звучат так:
GitFlow. Сразу стоит сказать, что эта стратегия дискуссионная. О ней есть много как положительных, так и отрицательных отзывов.
Суть в следующем. Есть два типа постоянных веток: master-ветка, чтобы понимать, как выглядит последняя актуальная версия, и development-ветка, где ведется разработка. От нее идут три вида временных веток.
В 2010 году вышел текст голландского программиста Винсента Дриссена «A successful Git branching model», в которой он впервые рассказал о GitFlow. Статья стала довольно популярной, появился русский перевод, а методика была взята на вооружение во многих командах.
В 2020 году американский программист Джордж Стокер выпустил статью «Please stop recommending Git Flow», где он раскритиковал метод, как устаревший и неэффективный в современных реалиях. Дриссен в ответ дополнил свой текст 2010 года дисклеймером, в котором признал, что его метод не панацея, а только один из вариантов организации работы.
Forking Workflow. Здесь подход такой: существует оригинальный репозиторий для мерджа всех изменений и его копия, в которой работает другой разработчик. Подход очень близок к идеологии open source, его цель — использовать все преимущества open-source-сообщества в рамках проекта. При этом большая часть рабочего процесса в части ветвления копирует GitFlow. Feature-ветки здесь будут мерджиться с локальными репозиториями разработчиков. Таким образом, разработка становится гибкой даже для очень больших команд с подрядчиками.
Среди тех, кто использует такой подход — Linux. Вы можете предложить свои варианты изменения кода даже для ядра системы. И этот подход, судя по всему, эффективно работает.
Общие моменты
Какую бы концепцию вы не выбрали, есть основные моменты, которых лучше придерживаться. Вот, например, правила Microsoft:
Вот еще несколько полезных принципов.
Называйте все просто и очевидно
Это поможет всем членам команды правильно понимать, кто над чем работает. Также допустимо включить в название ветки дополнительную информацию, например, имя создателя. Это тот случай, когда не нужно придумывать что-то оригинальное. Названия веток типа «пользователи», «багфикс», «feature», «hotfix» — то что надо. Для веток, работа в которых затягивается, используйте отдельные специальные флаги. Это позволит команде сразу понимать о чем идет речь и всегда держать в голове эти задачи как долгосрочные.
Слияние веток только через pull request
Механизм pull request зарекомендовал себя как логичный и хорошо придуманный. Так как этот процесс требует времени, вы должны принять внутри команды, что и в какие сроки ожидается от всех участников pull request. Распределите обязанности ревьюеров и расскажите об этом команде через внутреннюю базу знаний.
Вот немного конкретных советов:
Настройте branch policies
Потратить время на политики ветвления стоит по нескольким причинам:
Ветвление в Git: Где и Как Использовать Git Branch
Что Такое Git Branch
Git branching, или ветвление Git – отличный способ работать над нашим приложением и одновременно отслеживать его версии. Ветвь разработки – это бифуркация состояния кода, что создает новый путь для его эволюции. Вы можете генерировать разные ветки Git, которые будут существовать параллельно к главной ветке. Таким образом, вы сможете упорядоченно и точно включать новые функции в ваш код.
Использование Git Branches имеет несколько преимуществ. Тем не менее, мы хотим подчеркнуть следующие два:
Каждый разработчик может использовать собственные модели ветвления, исходя из своего опыта.
Где и как использовать Git Branch
Работать с Git branches довольно просто, это видно из самих команд. Но, как и в большинстве других случаев, чем больше у вас веток, тем сложнее управлять ими.
В любом проекте Git мы можем просмотреть все ветви, введя следующую команду в командной строке:
Если вы не создали ни одной Git branch, в терминале не будет выходных данных. Создать ветку действительно просто:
Затем нам нужно перейти в новую ветку Git, которую вы только что создали. Для этого мы запустим следующую команду:
Результат сообщит нам, что мы перешли в новую ветку. Мы назвали её тестовой, так что мы увидим следующее сообщение:
Теперь в этой новой ветви разработки мы можем создать столько модификаций кода, сколько захотим, без необходимости что-либо менять в основной Git branch. Как мы видим, это поддерживает готовность программы к добавлению новых частей кода.
Если мы запустим команду для повторного вывода списка ветвей, мы увидим, что добавлена новая ветка и что мы находимся в ней.
Есть кое-что, о чём мы должны помнить, создавая новую ветку разработки. Во-первых, мы должны сделать commit в основную ветку, чтобы Git понял, что это master branch. Если мы этого не сделаем, мы получим ошибку. Итак, сначала сделайте commit, а затем создавайте ветки разработки.
Если мы хотим удалить ветку из Git, мы можем сделать это с помощью следующей команды:
Однако, мы не можем находиться в той ветке, которую хотим удалить. Сначала мы перемещаемся в главную ветку и уже оттуда удаляем только что созданную:
Наконец, наступил момент, когда мы внесли много изменений в ветку разработки и она превратилась в стабильную, поэтому мы хотим связать её с другой веткой разработки. Для этого и существует команда слияния ( merge ).
Сначала найдите ветку разработки, к которой должна быть присоединена другая ветка. Например, мы хоти прикрепить тестовую ветвь к основной ветке – master branch. Для этого мы должны перейти в master branch и осуществить merge с помощью команды:
Как видите, основные функции ветки Git довольно просты. Вам просто нужно знать основы и стараться поддерживать порядок в своём проекте.
Выводы
Умение использовать Git branch, является очень важным, особенно, если вы работаете в команде. Организовывайте свой код в разных ветках Git с умом.
В этой статье мы научили вас основам работы с ветками Git.
Ольга уже около пяти лет работает менеджером в сфере IT. Написание технических заданий и инструкций — одна из её главных обязанностей. Её хобби — узнавать что-то новое и создавать интересные и полезные статьи о современных технологиях, веб-разработке, языках программирования и многом другом.