бранч что это такое в программировании
Словарь айтишника: на каком языке они говорят и как их понять
Каждый, кто когда-либо общался с айтишником, не раз переспрашивал его, что именно он имел ввиду. Даже если вы сами работаете в сфере ИТ и приходите в новую компанию, вы наверняка столкнетесь с профессиональным жаргоном и компьютерным сленгом, понять который не удается в первые несколько дней, а то и дольше. Какие-то слова вы возможно уже знаете, о смысле других догадываетесь, но точно мечтаете о том, чтобы вам дали специальный словарь, в котором будет все подробно расписано. Однако, спустя какое-то время вы и сами заговорите на их языке, это неизбежно.
Профессиональный жаргон существует не для того, чтобы испортить русский язык. Он позволяет ускорить устное общение ИТ-специалистов и наладить их взаимопонимание.
Так на каком языке говорят в ИТ-отделе? Ниже мы привели список самых популярных слов.
Баг — расхождение фактического и ожидаемого результата. Интересно, что произошло оно от одной из первых задокументированных ошибок в 1945 году, которая была вызвана жуком (bug), заползшим в шкаф древней ЭВМ и нарушившим ее работу. Пример: «Тестировщик нашел баг в проекте, нужно поправить». Здесь же можно добавить слово Фикс (фиксить, от англ. fix — исправлять). «Всю прошлую неделю фиксил эту странную багу».
Бранч (он же ветка) — полная копия проекта, в которой ведется разработка. В проекте может быть создано несколько веток, что позволяет работать одновременно с разными частями кода. «Посмотри изменения в моем бранче».
Смёржить — в системе контроля версий (git) выполнить слияние (merge) одного бранча в другой. Обычно применяется для обозначения вливания ветки, в которой велась разработка задачи, в основную после проверки другим программистом. Например, «Я смёржил FS-1024».
Конфа — в зависимости от контекста, помимо привычной всем «Конференция», название вики-системы для внутреннего использования (от англ. Confluence), которая помогает создавать единые базы знаний. «Нужно описать эту доработку в конфе, чтобы остальные тоже видели».
Жира (от англ. Jira) — популярная система для ведения задач в ИТ-проектах, которая помогает отслеживать ошибки. «Заведи задачу в жире».
Велосипедить — редкий случай, когда слово образовано не от его английского аналога, а от фразы «Изобретать велосипед», то есть решать, как правило с большим трудом, задачу, для которой уже имеется проверенное решение. «Не надо тут велосипедить, поищи готовое решение».
Ему противоположное — Костылить — решать проблему наспех и непродуманно, самым легким способом, который не учитывает всех возможных последствий и может создать новые проблемы. «Анализировать было некогда, багу быстро закостылили».
Стендап — нет, это не выступление комиков, а ежедневная встреча команды или планерка, на которой сотрудники рассказывают о проделанной работе, обсуждают проблемы и задачи. Примерно для того же самого используется слово Ретро (от слова ретроспектива) — на ИТ-сленге означает обсуждение проделанной работы за конкретный период (неделю, месяц, квартал). «Сегодня стендапа не будет! Обсудим все в конце недели на ретро».
Пыха — скриптовый язык программирования PHP, применяемый для разработки веб-приложений. «Есть ли в офисе специалисты по пыхе?».
Спиннер — элемент интерфейса: вращающаяся анимация на время ожидания. Слово произошло от той самой вращающейся игрушки, которые были популярны несколько лет назад. «Спиннер уже очень долго крутится, но ничего не происходит».
Репа (от англ. Repository) — хранилище, место, где хранятся и поддерживаются какие-либо данные. «Дай мне ссылку на репку, нужно скачать оттуда код».
Моки (от англ. mock up — макет, эскиз) — фиктивные данные, которые используются для отладки взаимодействия в информационных системах. «У нас еще не все готово, поэтому интерфейс частично на моках».
Билдить и деплоить (от англ. to build — собрать и to deploy — развернуть) — выполнять действия, направленные на перевод исходного кода в рабочее состояние на конкретном сервере. «Билдани проект, нужно задеплоить».
Автор статьи — архитектор отдела разработки финансового блока информационных систем CDEK IT.
Бранч-стратегии при разработке в 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 repository)
Гит-репозиторий — это облачное хранение вашего проекта на сервере (например, на сервере Гитхаба, но можно и на другом).
У каждого программиста может быть сколько угодно репозиториев, по одному на каждый проект. А можно вести все проекты в одном репозитории, но тогда это превратится в мешанину. Но каждый имеет право на мешанину.
В репозитории могут храниться:
Что такое бранч (git branch)
Бранч — это ветка или копия проекта, в которую можно вносить любые изменения и они не повлияют на основной проект.
В гит-репозитории всегда есть как минимум один бранч, который называется master. Если не создавать других веток, то все изменения будут сразу идти в главную ветку проекта. Для очень маленьких или учебных проектов это терпимо, но в любом коммерческом коде поступают иначе: создают ветки.
Дело в том, что ветка master используется для выпуска новых версий проекта, которые будут доступны всем. То, что добавляется в мастер-бранч, сразу становится доступно пользователям.
Но представьте такую ситуацию: мы только что запустили сайт для заказчика и он срочно хочет добавить интерактивный раздел со скидками. Можно сделать так: править рабочие файлы проекта «по живому», чтобы сразу видеть результат. А можно сделать из мастера отдельную ветку news и работать уже в ней (и это очень похоже на форк). В этом случае мы получим полную копию проекта, в которую можно вносить любые правки и они никак не повлияют на запущенный сайт. Мы в этой ветке пилим всё, что нужно клиенту, показываем ему результат на секретном сайте, а потом объединяем её с мастером. Это называется «смёржить бранчи».
Что такое клонирование (git clone)
Клонирование — это когда вы копируете репозиторий себе на жёсткий диск. Это нужно, чтобы начать в нём что-то менять.
Чем это отличается от простого копирования: когда вы клонируете репозиторий, вместе с файлами вашего проекта вы также тянете всю историю версий, все ветки, всю историю работы. И если кто-то дальше будет вносить изменения в проект, благодаря этим данным вы сможете тоже их получить.
А если просто скопировать нужные файлы с чужого компьютера, то никаких историй и никаких связей не сохранится. Синхронизации не будет. Просто какие-то файлы.
Что значит «смёржить» (git merge)
Смёржить (от англ. merge — объединять, совмещать) — это когда мы отправляем всё, что сделали в одной ветке, в другую. Весь новый код, исправления ошибок, дополнительные функции — всё это отправится в новую ветку. Если же мы что-то удалим в коде, то при объединении этот фрагмент тоже удалится из основной ветки.
Получается, что схема работает так:
Что такое коммит (git commit)
Программировать только в облаке неудобно — проще скачать себе на компьютер весь проект и писать код на своей машине. Но чтобы правки увидели остальные, их нужно отправить обратно в репозиторий. Это и есть коммит.
Коммитить можно и один файл, и сразу несколько. Система сама найдёт, что изменилось в каждом файле, и добавит эти изменения в проект. Но все эти правки внесутся в репозиторий за один раз, потому что при коммите обрабатываются сразу все добавленные в список файлы.
Например, вы изменили файл главной страницы index.html и добавили его в список файлов текущего коммита. Теперь его можно отправить на сервер, а можно ещё поправить сразу style.css и внести в этот же коммит. Системе всё равно, сколько файлов обрабатывать, поэтому как и что коммитить — решает программист.
Единственное требование к коммитам — указывать, что именно вы поменяли в проекте, человеческим языком. Хорошим тоном и правильным подходом считается писать, что именно вы изменили: «Добавил цвет и стили основной кнопки», «Убрали метод вызова старого API», «Сделали рефакторинг функции SetOutOfDate()». Это описание будут читать другие разработчики.
Коммитить можно хоть после правки каждой строчки — весь вопрос в том, насколько нужна такая детализация в проекте. Но иногда и изменения из одной строчки можно закоммитить, если оно действительно важное.
Что такое пуш- и пулл-реквесты (git push, git pull)
Чтобы отправить данные из своего проекта на сервер, используют пуш-реквесты. Для этого программист указывает имя ветки, в которую хочет отправить свой код, а сервер их принимает, проверяет и добавляет к себе.
Иногда бывает так, что сервер отказывает в пуш-реквестах, потому что у программиста на компьютере была неактуальная ветка. За то время, пока он писал свои правки, другие программисты сделали несколько изменений, закоммитили их у себя и отправили на сервер. Получилось, что у одних эта ветка осталась свежей и актуальной, а у других она устарела. Чтобы не принимать пуш-реквесты из устаревших веток, гитхаб просит сначала обновить данные у себя на комьютере с помощью пулл-реквеста.
Пулл-реквест работает просто: он скачивает с сервера актуальную версию ветки и добавляет код оттуда вам на компьютер. Иногда этот код вступает в противоречие с тем, что уже успел сделать программист, и тогда возникает конфликт — нужно принять решение, какая версия одинакового кода останется в проекте, а что нужно будет убрать.
Чем коммит отличается от пуш-реквеста
Коммит — это когда вы фиксируете изменения в проекте, как бы подводите итог своей работе.
Пуш — это когда вы отправляете сделанную работу туда, где хранится копия вашего кода.
Получается, последовательность действий такая:
Что дальше
Чтобы все эти бранчи и реквесты стали понятнее, в следующий раз сделаем вот что: заведём учебный проект на Гитхабе и будем работать с ним так, как делают настоящие программисты.
Основы использования бранчинга для параллельной разработки
Как справедливо заметил 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, и самыми нестабильными являются ветки для разработки. Как правило, на диаграммах самые стабильные ветки отображаются выше всех, а нестабильные – ниже всех.
Накладные расходы, связанные с использованием бранчинга
С бранчингом связаны следующие издержки:
Типы зависимостей между ветками и способы их решения
Между ветками могут возникать следующие зависимости:
Существует несколько типовых решений для работы с таким зависимостями:
Важно понимать, что грамотный модульный дизайн приложения может сильно уменьшить или свести на нет необходимость использования бранчинга и является мощным инструментом для решения проблем, связанных с параллельной разработкой.
Бранчинг позволяет нам одновременно вести два вида разработки: стабилизацию и реализацию нового функционала. Однако, это не единственный способ его применения. Например, отдельные ветки могут выделяться для разделения итераций или для изоляции разных команд.
Правильный выбор стратегии бранчинга зависит от потребностей проекта и возможностей/ограничений используемой системы управления версиями (которую, впрочем, никто не запрещает сменить). Ограничения реального мира, которые накладываются на процесс, часто невозможно решить без возможности осуществления паралелльной разработки. Тем не менее, неграмотное понимание и использование бранчинга часто приводит к анти-паттернам, которые и завершают этот материал.
среда, 21 апреля 2021 г.
Что такое бранч (отдельная ветка в коде) и зачем она нужна
Это выдержка из моей статьи «Что такое VCS (система контроля версий)». Нужна именно как напоминание «что такое бранч», если с самой системой контроля версий вы уже знакомы
— Бранч — это отдельная ветка в коде. Вот смотрите, мы сейчас работаем в trunk-е, основной ветке.
Когда мы только-только добавили наш код на сервер, у нас появилась «точка возврата» — сохраненная версия кода, к которой мы можем обратиться в любой момент.
Потом разработчик добавляет новый функционал и коммитит его — это версия 1 кода.
Потом он добавляет еще функционал — это версия кода 2.
При этом в самой VCS сохранены все версии, и мы всегда можем:
Посмотреть изменения в версии 1
Сравнить файлы из версии 1 и версии 2 — система наглядно покажет, где они совпадают, а где отличаются
Откатиться на прошлую версию, если версия 2 была ошибкой.
Потом разработчик снова добавляет код — это версия 3.
Теперь, если я захочу закоммитить изменения, они по-прежнему пойдут в основную ветку. Бранч при этом трогать НЕ будут (изменения идут в ту ветку, в которой я сейчас нахожусь. В этом примере мы создали branch, но работать продолжаем с trunk, основной веткой)
Так что мы можем смело коммитить новый код в trunk. А для показа заказчику использовать branch, который будет оставаться стабильным даже тогда, когда в основной ветке всё падает из-за кучи ошибок.
С бранчами мы всегда будем иметь работающий код!
Вы можете спросит — «Зачем эти сложности? Мы ведь всегда может просто откатиться на нужную версию! Например, на версию 2. И никаких бранчей делать не надо!».
Это верно. Но тогда нужно будет всегда помнить, в какой точке «всё работает и тут есть все нужные функции». А если делать говорящие названия бранчей, обратиться к ним намного проще. К тому же иногда надо вносить изменения именно в тот код, который на продакшене (то есть у заказчика).
Допустим, мы выпустили сборку 3, идеально работающую. Спустя неделю Заказчик ее установил, а спустя месяц нашел баг. У нас за эти недели уже 30 новых коммитов есть и куча изменений.
Заказчику нужно исправление ошибки, но он не готов ставить новую версию — ведь ее надо тестировать, а цикл тестирования занимает неделю. А баг то нужно исправить здесь и сейчас! Получается, нам надо:
Обновиться на версию 3
Исправить баг локально (на своей машине, а не в репозитории)
Никуда это не коммитить = потерять эти исправления
Собрать сборку локально и отдать заказчику
Не забыть скопипастить эти исправления в актуальную версию кода 33 и закоммитить (сохранить)
Что-то не очень весело. А если нужно будет снова дорабатывать код? Искать разработчика, у которого на компьютере сохранены изменения? Или скопировать их и выложить на дропбокс? А зачем тогда использовать систему контроля версий?
Именно для этого мы и бранчуемся! Чтобы всегда иметь возможность не просто вернуться к какому-то коду, но и вносить в него изменения. Вот смотрите, когда Заказчик нашел баг, мы исправили его в бранче, а потом смерджили в транк.
Смерджили — так называют слияние веток. Это когда мы внесли изменения в branch и хотим продублировать их в основной ветке кода (trunk). Мы ведь объединяем разные версии кода, там наверняка есть конфликты, а разрешение конфликтов это merge, отсюда и название!
Если Заказчик захочет добавить новую кнопочку или как-то еще изменить свою версию кода — без проблем. Снова вносим изменения в нужный бранч + в основную ветку.
Веток может быть много. И обычно чем старше продукт, тем больше веток — релиз 1, релиз 2. релиз 52.
Есть программы, которые позволяют взглянуть на дерево изменений, отрисовывая все ветки, номера коммитов и их описание. Именно в таком стиле, как показано выше =) В реальности дерево будет выглядеть примерно вот так (картинка из интернета):
А иногда и ещё сложнее!
— А как посмотреть, в какой ветке ты находишься?
— О, для этого есть специальная команда. Например, в Mercurial это «hg sum»: она показывает информацию о том, где ты находишься. Вот пример ее вызова:
В данном примере «parent» — это номер коммита. Мы ведь можем вернуться на любой коммит в коде. Вдруг мы сейчас не на последнем, не на актуальном? Можно проверить. Тут мы находимся на версии 3. После двоеточия идет уникальный номер ревизии, ID кода.
Потом мы видим сообщение, с которым был сделан коммит. В данном случае разработчик написал «Try to fix bug with device».
И, наконец, параметр «branch»! Если там значение default — мы находимся в основной ветке. То есть мы сейчас в trunk-е. Если бы были не в нём, тут было бы название бранча. При создании бранча разработчик даёт ему имя. Оно и отображается в этом пункте.
Отдельно хочу заметить, что бранчевание на релиз — не единственный вариант работы с VCS. Есть и другой подход к разработке — когда транк поддерживают в актуальном и готовом к поставкам состоянии, а все задачи делают в отдельных ветках. Но его мы в этой статье рассматривать не будем.
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков