Чем ветвление помогает в работе qa
Эффективная стратегия ветвления Git, о которой должен знать каждый разработчик
Для тех, кто хочет научиться эффективно работать в команде и применять Git, в Слёрме подготовили практический курс и перевод интересного материала о стратегии ветвления.
Цель стратегии ветвления в том, чтобы повысить стабильность кода и продуктивность разработчиков и избежать лишних конфликтов.
Я не буду затрагивать все типы стратегий ветвления, но я назову лучшую, которая применяется чаще всего.
Разделение на эти три типа ветки помогает избегать ненужных конфликтов и повышает продуктивность команды.
Однако мы пропустили одну вещь: тестирование QA.
На какой ветке его делать? Другими словами, какую ветку следует развернуть в среде QA?
Самый простой подход: иметь среду QA на ветке разработки (т. е. серверы QA будут развернуты со сборкой, выпускаемой из ветки develop ). А после завершения тестирования и контроля качества создается MR/PR в ветку master.
Чтобы решить эту проблему, разработчику нужно отменить коммит отмены.
Для продуктивности команды я бы порекомендовал второй путь.
Таким образом появится дополнительный шаг, и весь функциональный цикл будет выглядеть следующим образом:
Преимущества этого подхода
Несмотря на то, что этот подход внешне очень похож на предыдущий и, на первый взгляд, у добавления еще одной ветви нет особых преимуществ, он поможет увеличить продуктивность следующим образом:
Чем ветвление помогает в работе qa
Что пишут в блогах
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Ирина Соколова, Senior QA Engineer, qualsolife.ru
Предыстория
Недавно одна моя знакомая QA Engineer, которая долгое время работала в вялотекущем проекте, где круг ее обязанностей был строго очерчен, сменила работу и устроилась в свежезапущенный проект. Просидев пару дней без обозначенных сверху заданий, и откровенно заскучав, она пошла к руководству с вопросом «Что мне делать?» на что получила многозначительный ответ «Организуй свою работу». И тут она впала в ступор «А это как?». И правда, как?
Несколько месяцев назад я сама сменила работу и попала в английский проект, в котором никогда раньше не было QA. Сам проект существует давно. Как часто бывает, компания, в которой много денег, купила компанию, в которой денег поменьше, но есть клиенты. В итоге, крупная компания получила новых клиентов и минус одного конкурента на рынке. Мой проект получил смену менеджмента и принципов управления.
В первые же дни знакомства с новой командой, я услышала честный недоумевающий вопрос одного из разработчиков Лондонского офиса «А что ты будешь здесь делать?»
По правде говоря, придя в этот проект и за несколько дней оглядевшись по сторонам, я, как и моя коллега, поначалу немного впала в ступор. Не потому что я не знала, что делать. Скорее, я не знала как грамотно себя вклинить в сложившиеся здесь устои. Команда разработчиков замечательно существовала без тестировщиков. Они использовали канбан, принципы continuous delivery, бесстрашно, спокойно и уверенно деплоили на production почти каждый день, даже по пятницам. А все потому, что у них было прекрасное покрытие автотестами. Пожалуй, лучшее, что я когда-либо встречала. Ревьюя пулл реквесты друг друга, они не стеснялись подсказывать друг другу какие еще автотестов добавить. Автор текущего изменения сам деплоил свою работу на production, а значит, полностью сам нес ответственность за свою работу. И он ее нес, несмотря на то, что на проекте появилась я … и перед деплоем неплохо было бы услышать и мое мнение.
Но все же, разумеется, процесс не был безупречным: бывало, что разработчики не понимали требований, пропускали баги и довольно часто на стороне заказчиков случались какие-то проблемы, которые требовали принятия мер.
Столкнувшись с необходимостью определения моего положения в команде я тоже пошла к руководству. Только диалог наш был выстроен совсем иначе, не так как у моей знакомой.
Организация работы QA Инженера
Задаем нужные вопросы
Итак. На диалог я созвала руководство и ведущих разработчиков проекта. Есть одно замечательное правило менеджмента, о котором я, конечно же, забыть не могла: озвучивая проблему, озвучивай и вариант ее решения, хотя бы один.
Тем не менее, у меня было два вопроса, ответы на которых я знать не могла. С них проще всего и было начать.
Первый вопрос. Что из себя представляет структура организации, а именно кто над кем стоит и кто за что отвечает?
В идеале у компаний должна быть иерархично представленная схема иллюстрирующая структуру компании. Но я нахожусь не в идеале, поэтому было важно выяснить к кому с какими вопросами и предложениями можно идти.
Второй вопрос. Компания ввела в проект QA Engineer, каковы их ожидания относительно меня, какие цели они преследовали открывая эту позицию?
Когда ответ очень конкретизирован, это во многом определяет фронт работы. В моем случае ответ содержал много общих размытых фраз, которые я восприняла как «делай, что хочешь, но чтобы у нас все было хорошо».
На этом первая часть дискуссии закончилась.
Обсуждаем план действий
Вторая часть обсуждений, и пожалуй, наиболее важная, представляла собой презентацию моего плана работы и ее обоснование. Мне нужно было получить благословение вышестоящих лиц для беспрепятственного внедрения себя и своей деятельности в проект.
Приятно очевидно, что умные книжки и теория существуют не на пустом месте, поэтому я вооружилась познаниями, полученными при подготовке к сертификации ISTQB, когда-то из любопытства прочитанными книгами по теории тестирования и Скраму, пропустила это все через сито десятилетнего опыта работы и составила пилотный проект для QA Strategy.
Тезисно обсужденный с руководством и всесторонне им поддержанный, позже он обрел формат официального документа компании. Дальше я хочу поделиться идейными рекомендациями для составления такого документа. Они сложились как квинтэссенция предыдущего опыта и пройденного пути на текущем проекте. И, пожалуй, я в виде цитат перепечатаю сюда некоторые фрагменты в первозданном мной виде: на английском языке. Уверена, что для каждого QA Engineer составление подобного плана станет ключевым ответом на вопрос «Как организовать свою работу»
Формируем QA Strategy
1. Введение в Quality Assurance
Напомните/впервые познакомьте с термином Quality Assurance. Поверьте, у вас в команде полно людей, которые очень смутно представляют себе, что это такое. Совсем общие определения можно позаимствовать из википедии. Тактично обозначьте, что присутствие команды QA на проект не означает, что вся ответственность за качество работы теперь перекладывается только на них:
Testing is a part of QA. It allows us to determine the level of quality of the feature(s) that we are assessing.
It is not the sole responsibility of testers to carry out QA. The entire team can and should contribute to ensure a high level of quality of the products and services being delivered.
2. Введение в QA Strategy
Подготовьте к тому, о чем дальше люди будут читать.
The Testing Strategy is an evolving document detailing the processes and way we are going to ensure the quality of our product going forward.
Озвучьте контент. Это может быть как просто оглавление, так и более тезисные предложения. Здесь упомяните о существовании Подхода к тестированию (Test Approach), Процессов тестирования (Test Process), Стратегия создания автотестов (Test Automation Strategy) и необходимости Тест плана (Test Plan).
Важно. Обозначьте временной интервал пересмотра этого документа. И проект и процессы в компании развиваются, этот документ не должен превращаться в динозавра. Поэтому запланируйте дату, когда ваша стратегия будет пересмотрена и изменена. По-моему, шести месяцев для того, чтобы вернуться с новыми мыслями вполне достаточно.
3. Test Approach
Что такое подход к тестированию? Немного отстранившись от объемной официальной формулировки этого определения, я позволю себе упростить его до тезиса, что это «базисные мысли, с которыми мы каждый день приступаем к работе». Запишите здесь: что есть двигатель вашего прогресса?
Классика жанра и хорошо работающие подходы – это «действующий на опережение» (proactive) и «основанный на рисках» (risk-based).
We will be adopting a proactive and risk-based testing approach.
Proactive — This means that the test design process is initiated as early as possible in order to find and fix the defects before the build is created.
Risk-based — This means that we will organize our testing efforts in a way that reduces the level of product risk when the system ships. According to the ISTQB syllabus «Risk-based testing is the idea that we can organize our testing efforts in a way that reduces the residual level of product risk when the system ships. Risk-based testing uses risk to prioritize and emphasize the appropriate tests during test execution, but it’s about more than that. Risk-based testing starts early in the project, identifying risks to system quality and using that knowledge of risk to guide testing planning, specification, preparation and execution. Risk-based testing involves both mitigations — testing to provide opportunities to reduce the likelihood of defects, especially high-impact defects — and contingency — testing to identify workarounds to make the defects that do get past us less painful. Risk-based testing also involves measuring how well we are doing at finding and removing defects in critical areas»
Когда мы говорим про опережение, мы, в первую очередь, должны говорит о контроле качества спецификации требований. Менеджеры, которые составляют спецификации элементов очередного цикла разработки, в большинстве своем мыслят как простые пользователи системы, в то время как логика мыслей разработчиков существует в другом измерении. Во-первых, не раз я видела такое, что разработчик, читая спецификацию, не может перевести ее на язык программирования. Например, не может сопоставить упомянутого в спецификации пользователя с существующими в системе ролями/правами доступа. В итоге он может подобрать наиболее подходящую, по его личному мнению, роль, которая окажется не той и придется возвращать функциональность в работу позже и терять время; либо задать вопрос менеджеру, который, быть может, ушел в отпуск и снова терять время в ожидании. QA Engineer это та замечательная прослойка между заточенным на пользователя менеджером и технически мыслящим разработчиком, особенно, если QA Engineer не пренебрегает бело ящичным тестированием. Именно мы способны понять менеджеров и перевести их мысли разработчикам. Вовремя.
Тестирование, основанное на рисках, имеет под собой интересные формальные методы оценки рисков проекта и рисков продукта. Очень здорово уметь их применять на практике. Но лично мне никогда не хватает времени расписывать вероятности возникновения, тяжесть их последствий и т.п. и рассчитывать риски по всем правилам. Здесь я полностью полагаюсь больше на свое чутье и здравый смысл. При тестировании или покрытии автотестами зоны риска (то чему нужно уделить первое и основное внимание) в большинстве своем:
4. Test Process
Расскажите, какой методолгической последовательности работы вы рассчитываете придерживаться. Я не стала изобретать ничего сложного, а взяла идею из ISTQB и пользуюсь.
Если пойдете по моему пути, ознакомьтесь с последовательностью работы, которую рекомендуют авторы ISTQB, осознайте то, какие шаги вы будете выполнять и как. Начинаем мы с планирования и контроля. Эти двое живут вместе, т.к. на основе мониторинга своей же деятельности, планы могут регулярно перекраиваться. Дальше идут работа с документацией и написание тест кейсов, их ввод в эксплуатацию (задействование спланированных тестовых данные и подходящего окружения), завершение тестирования и уборка за собой (удалить временные файлы и т.п.)
We will use the test process outlined in the Foundation level ISTQB syllabus: Test Planning and Control, Test Analysis and Design, Test Implementation and Execution, Evaluating Exit Criteria and Reporting, and Test Closure Activities.
5. Responsibilities
Обозначьте свои и чужие обязанности на поприще повышения качества продукта. Донесите свою миссию.
Во-первых, акцентируйте снова, что каждый член команды сам по себе тестировщик, все тестируют то, чего они касаются. Написал код – протестируй его.
Во-вторых, разъясните и уясните направление своего постоянного развития. QA Инженер — главный эксперт по функциональности продукта: знает, как и что работает, способен объяснить, как и что нужно тестировать. Он – человек, который предугадает эксплуатационное поведение заказчика, а значит, не позволит развиться серьезным проблемам.
В-третьих, обозначьте способ взаимодействия с менеджерами и разработчиками. Например, остановитесь на Three amigos agile approach
Collaboration between Business, Development and QA
a. Business — What problem are we trying to solve?
b. Development — How might we build a solution to solve that problem?
c. Testing — What about this, what could possibly happen
6. Testing Levels and QA Automation Strategy
На сегодня этот раздел у меня стал отдельным самодостаточным документом. Но на уровне организации зарождающегося QA процесса в команде, обозначьте какие виды тестирования кто будет исполнять. Что будет выполняться вручную, что автоматизироваться и по какому принципу. Кто за какие автотесты отвечает.
Например, на текущем проекте я пишу только end-to-end тесты, бесперебойная работа которых стратегически важна с точки зрения бизнеса. При этом я смотрю пулл реквесты разработчиков и при необходимости даю рекомендации о покрытии тестами. Все остальные (юнит, интеграционный, нагрузочные и т.п) — это работа разработчиков. На предыдущем проекте — нагрузочное тестирование было на мне, а интеграционные тесты я писала наравне с разработчиками.
7. Feature workflow
Сегодня мой проект работает по Скраму, используя двухнедельные спринты. Поэтому у меня есть пошагово прописаный документ жизненного цикла для каждой Story.
Какой бы методологии не придерживался проект, опишите, как шаг за шагом делать ежедневную работу. Если выше мы говорили больше о тактике действий, то здесь должны быть четкие указания, что сначала, что потом.
Например, мой вариант такой
The workflow below details the process that we will adopt internally.
1. Get story before planning session
2. Create a checklist according to acceptance criteria and the description
3. Note unclear details/questions
4. Clarify questions on planning
5. Update the checklist
6. Highlight any dependencies and how you’re going to overcome them
7. When the story is in Review check if acceptance criteria are covered by autotests
8. Encourage developer to cover all acceptance criteria with autotests or do it yourself
9. When the story is ready for testing perform manual testing using the checklist
10. Create bugs for the story if they exist and return the item to development
11. When bugs are fixed perform manual testing using the checklist again
12. Check if all autotests are passed
13. Create a task for implementing additional integration autotests if it is needed
14. Move story in QA Passed state
8. Test Plan
Выберите вид Тест Плана, платформу на которой вы будете ее хранить и цель его существования. Обеспечьте способ любому желающему туда заглянуть.
На данном проекте мой Тест План — это набор чеклистов для каждой Story. При имеющемся уровне автоматизации пока этого достаточно.
На прошлом проекте Тест План использовался для основательного ручного тестирования и как идейный базис для грядущих автотестов.
Если у вас много ручных тестов, тест кейсы пишите подробно, так, чтобы любой новый QA инженер, придя на проект смог их выполнить самостоятельно.
Как работать с документом
Написать весь этот план и эффектные слова это очень здорово. Начальство оценит, не сомневаюсь. Но есть один важный момент существования этого документа. Это честные ответы на вопросы для кого и для чего все это написано?
Прописывая каждое предложение, хорошо бы задумываться над вопросами: «Я, действительно, хочу так работать?», «Я, действительно, буду воплощать это в жизнь на проекте?»
Если оба ответа положительны, уверенно печатать дальше.
Если один из ответов – «Нет», по-моему, это верный знак не вешать на себя ненужных обязанностей.
Если один из ответов – из ряда «Пока не знаю», пусть пока живет на ваших страницах.
У меня такие моменты оставались в списке того, что первым делом будет пересматриваться через несколько месяцев.
Свой документ я, в первую очередь, писала для себя. У меня случаются моменты, когда я отступаю от описанных процессов и даже немного иду им вразрез. Приспосабливаться к ситуации, чтобы эффективно использовать ресурсы здесь и сейчас – это нормально. Но в преобладающем большинстве своем, при обычной рутинной работе, мой документ – это мой путеводитель. Не раз убеждалась, имеющийся план/стратегия в любой сфере всегда приближает к желаемым результатам быстрее и с меньшей болью, чем его полное отсутвие. Желаю Вам строить свою работу легко и эффективно!
Перед самой публикацией статья была сильно сокращена, уж больно большой она показалась мне. Буду рада продолжить эту тематику позже. Тем не менее, я всегда рада развиваться, если есть что-то о чем я совершенно забыла, пожалуйста, напишите мне в комментарии.
Удачная модель ветвления для Git
В этой статье я представляю модель разработки, которую использую для всех моих проектов (как рабочих, так и частных) уже в течение года, и которая показала себя с хорошей стороны. Я давно собирался написать о ней, но до сих пор не находил свободного времени. Не буду рассказывать обо всех деталях проекта, коснусь лишь стратегии ветвления и управления релизами.
В качестве инструмента управления версиями всего исходного кода она использует Git.
Почему Git?
За полноценным обсуждением всех достоинств и недостатков Git в сравнении с централизованными системами контроля версий обращайтесь к всемирной сети. Там Вы найдёте достаточное количество споров на эту тему. Лично же я, как разработчик, на данный момент предпочитаю Git всем остальным инструментам. Git реально смог изменить отношение разработчиков к процессам слияния и ветвления. В классическом мире CVS/Subversion, из которого я пришёл, ветвление и слияние обычно считаются опасными («опасайтесь конфликтов слияния, они больно кусаются!»), и потому проводятся как можно реже.
Но с Git эти действия становятся исключительно простыми и дешёвыми, и потому на деле они становятся центральными элементами обычного ежедневного рабочего процесса. Просто сравните: в книгах по CVS/Subversion ветвление и слияние обычно рассматриваются в последних главах (для продвинутых пользователей), в то время как в любой книге про Git они бывают упомянуты уже к третьей главе (основы).
Благодаря своей простоте и предсказуемости, ветвление и слияние больше не являются действиями, которых стоит опасаться. Теперь инструменты управления версиями способны помочь в ветвлении и слиянии больше, чем какие-либо другие.
Но хватит говорить об инструментах, давайте перейдём к модели разработки. Модель, которую я хочу представить, — это, по сути, просто набор процедур, которые исполняет каждый член команды, чтобы все вместе могли достичь высокой управляемости процесса разработки.
Децентрализованный, но централизованный
Предлагаемая модель ветвления опирается на конфигурацию проекта, содержащую один центральный «истинный» репозиторий. Замечу, что этот репозиторий только считается центральным (так как Git является DVCS, у него нет такой вещи, как главный репозиторий, на техническом уровне). Мы будем называть этот репозиторий термином origin, т.к. это имя и так знакомо всем пользователям Git.
Каждый разработчик забирает и публикует изменения (pull & push) в origin. Но, помимо централизованных отношений push-pull, каждый разработчик также может забирать изменения от остальных коллег внутри своей микро-команды. Например, этот способ может быть удобен в ситуации, когда двое или более разработчиков работают вместе над большой новой фичей, но не могут издать незавершённую работу в origin раньше времени. На картинке выше изображены подгруппы Алисы и Боба, Алисы и Дэвида, Клэр и Дэвида.
Технически это реализуется несложно: Алиса создаёт удалённую ветку Git под названием bob, которая указывает на репозиторий Боба, а Боб делает то же самое с её репозиторием.
Главные ветви
Мы считаем ветку origin/master главной. То есть, исходный код в ней должен находиться в состоянии production-ready в любой произвольный момент времени.
Ветвь origin/develop мы считаем главной ветвью для разработки. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза. Эту ветку также можно назвать «интеграционной». Она служит источником для сборки автоматических ночных билдов.
Когда исходный код в ветви разработки (develop) достигает стабильного состояния и готов к релизу, все изменения должны быть определённым способом влиты в главную ветвь (master) и помечены тегом с номером релиза. Ниже мы рассмотрим этот процесс в деталях.
Следовательно, каждый раз, когда изменения вливаются в главную ветвь (master), мы по определению получаем новый релиз. Мы стараемся относиться к этому правилу очень строго, так что, в принципе, мы могли бы использовать хуки Git, чтобы автоматически собирать наши продукты и выкладывать их на рабочие сервера при каждом коммите в главную ветвь (master).
Вспомогательные ветви
Помимо главных ветвей master и develop, наша модель разработки содержит некоторое количество типов вспомогательных ветвей, которые используются для распараллеливания разработки между членами команды, для упрощения внедрения нового функционала (features), для подготовки релизов и для быстрого исправления проблем в производственной версии приложения. В отличие от главных ветвей, эти ветви всегда имеют ограниченный срок жизни. Каждая из них в конечном итоге рано или поздно удаляется.
Конечно же, с технической точки зрения, у этих ветвей нет ничего «специфического». Разбиение ветвей на категории существует только с точки зрения того, как они используются. А во всём остальном это старые добрые ветви Git.
Ветви функциональностей (feature branches)
Могут порождаться от: develop
Должны вливаться в: develop
Соглашение о наименовании: всё, за исключением master, develop, release-* или hotfix-*
Ветви функциональностей (feature branches), также называемые иногда тематическими ветвями (topic branches), используются для разработки новых функций, которые должны появиться в текущем или будущем релизах. При начале работы над функциональностью (фичей) может быть ещё неизвестно, в какой именно релиз она будет добавлена. Смысл существования ветви функциональности (feature branch) состоит в том, что она живёт так долго, сколько продолжается разработка данной функциональности (фичи). Когда работа в ветви завершена, последняя вливается обратно в главную ветвь разработки (что означает, что функциональность будет добавлена в грядущий релиз) или же удаляется (в случае неудачного эксперимента).
Ветви функциональностей (feature branches) обычно существуют в репозиториях разработчиков, но не в главном репозитории (origin).
Создание ветви функциональности (feature branch)
При начале работы над новой функциональностью делается ответвление от ветви разработки (develop).
Добавление завершённой функциональности в develop
Завершённая функциональность (фича) вливается обратно в ветвь разработки (develop) и попадает в следующий релиз.
Конечно, такой подход создаёт некоторое дополнительное количество (пустых) объектов коммитов, но получаемая выгода более чем оправдывает подобную цену.
Ветви релизов (release branches)
Могут порождаться от: develop
Должны вливаться в: develop и master
Соглашение о наименовании: release-*
Ветви релизов (release branches) используются для подготовки к выпуску новых версий продукта. Они позволяют расставить финальные точки над i перед выпуском новой версии. Кроме того, в них можно добавлять минорные исправления, а также подготавливать метаданные для очередного релиза (номер версии, дата сборки и т.д.). Когда вся эта работа выносится в ветвь релизов, главная ветвь разработки (develop) очищается для добавления последующих фич (которые войдут в следующий большой релиз).
Новую ветку релиза (release branch) надо порождать в тот момент, когда состояние ветви разработки полностью или почти полностью соответствует требованиям, соответствующим новому релизу. По крайней мере, вся необходимая функциональность, предназначенная к этому релизу, уже влита в ветвь разработки (develop). Функциональность, предназначенная к следующим релизам, может быть и не влита. Даже лучше, если ветки для этих функциональностей подождут, пока текущая ветвь релиза не отпочкуется от ветви разработки (develop).
Очередной релиз получает свой номер версии только в тот момент, когда для него создаётся новая ветвь, но ни в коем случае не раньше. Вплоть до этого момента ветвь разработки содержит изменения для «нового релиза», но пока ветка релиза не отделилась, точно неизвестно, будет ли этот релиз иметь версию 0.3, или 1.0, или какую-то другую. Решение принимается при создании новой ветви релиза и зависит от принятых на проекте правил нумерации версий проекта.
Создание ветви релиза (release branch)
Ветвь релиза создаётся из ветви разработки (develop). Пускай, например, текущий изданный релиз имеет версию 1.1.5, а на подходе новый большой релиз, полный изменений. Ветвь разработки (develop) готова к «следующему релизу», и мы решаем, что этот релиз будет иметь версию 1.2 (а не 1.1.6 или 2.0). В таком случае мы создаём новую ветвь и даём ей имя, соответствующее новой версии проекта:
Мы создали новую ветку, переключились в неё, а затем выставили номер версии (bump version number). В нашем примере bump-version.sh — это вымышленный скрипт, который изменяет некоторые файлы в рабочей копии, записывая в них новую версию. (Разумеется, эти изменения можно внести и вручную; я просто обращаю Ваше внимание на то, что некоторые файлы изменяются.) Затем мы делаем коммит с указанием новой версии проекта.
Эта новая ветвь может существовать ещё некоторое время, до тех пор, пока новый релиз окончательно не будет готов к выпуску. В течение этого времени к этой ветви (а не к develop) могут быть добавлены исправления найденных багов. Но добавление крупных новых изменений в эту ветвь строго запрещено. Они всегда должны вливаться в ветвь разработки (develop) и ждать следующего большого релиза.
Закрытие ветви релиза
Когда мы решаем, что ветвь релиза (release branch) окончательно готова для выпуска, нужно проделать несколько действий. В первую очередь ветвь релиза вливается в главную ветвь (напоминаю, каждый коммит в master — это по определению новый релиз). Далее, этот коммит в master должен быть помечен тегом, чтобы в дальнейшем можно было легко обратиться к любой существовавшей версии продукта. И наконец, изменения, сделанные в ветви релиза (release branch), должны быть добавлены обратно в разработку (ветвь develop), чтобы будущие релизы также содержали внесённые исправления багов.
Первые два шага в Git:
Теперь релиз издан и помечен тегом.
Чтобы сохранить изменения и в последующих релизах, мы должны влить эти изменения обратно в разработку. Делаем это так:
Этот шаг, в принципе, может привести к конфликту слияния (нередко бывает, что причиной конфликта является изменение номера версии проекта). Если это произошло, исправьте их и издайте коммит.
Теперь мы окончательно разделались с веткой релиза. Можно её удалять, потому что она нам больше не понадобится:
Ветви исправлений (hotfix branches)
Могут порождаться от: master
Должны вливаться в: develop и master
Соглашение о наименовании: hotfix-*
Ветви для исправлений (hotfix branches) весьма похожи на ветви релизов (release branches), так как они тоже используются для подготовки новых выпусков продукта, разве лишь незапланированных. Они порождаются необходимостью немедленно исправить нежелательное поведение производственной версии продукта. Когда в производственной версии находится баг, требующий немедленного исправления, из соответствующего данной версии тега главной ветви (master) порождается новая ветвь для работы над исправлением.
Смысл её существования состоит в том, что работа команды над ветвью разработки (develop) может спокойно продолжаться, в то время как кто-то один готовит быстрое исправление производственной версии.
Создание ветви исправлений (hotfix branch)
Ветви исправлений (hotfix branches) создаются из главной (master) ветви. Пускай, например, текущий производственный релиз имеет версию 1.2, и в нём (внезапно!) обнаруживается серьёзный баг. А изменения в ветви разработки (develop) ещё недостаточно стабильны, чтобы их издавать в новый релиз. Но мы можем создать новую ветвь исправлений и начать работать над решением проблемы:
Не забывайте обновлять номер версии после создания ветви!
Теперь можно исправлять баг, а изменения издавать хоть одним коммитом, хоть несколькими.
Закрытие ветви исправлений
Когда баг исправлен, изменения надо влить обратно в главную ветвь (master), а также в ветвь разработки (develop), чтобы гарантировать, что это исправление окажется и в следующем релизе. Это очень похоже на то, как закрывается ветвь релиза (release branch).
Прежде всего надо обновить главную ветвь (master) и пометить новую версию тегом.
Следующим шагом переносим исправление в ветвь разработки (develop).
У этого правила есть одно исключение: если в данный момент существует ветвь релиза (release branch), то ветвь исправления (hotfix branch) должна вливаться в неё, а не в ветвь разработки (develop). В этом случае исправления войдут в ветвь разработки вместе со всей ветвью релиза, когда та будет закрыта. (Хотя, если работа в develop требует немедленного исправления бага и не может ждать, пока будет завершено издание текущего релиза, Вы всё же можете влить исправления (bugfix) в ветвь разработки (develop), и это будет вполне безопасно).
И наконец, удаляем временную ветвь:
Заключение
Хотя в этой модели ветвления совершенно нет ничего принципиально нового, «большая картинка», с которой начинается эта статья, зарекомендовала себя в наших проектах с самой лучшей стороны. Она формирует элегантную мысленную модель, которую легко полностью охватить одним взглядом, и которая позволяет сформировать у команды совместное понимание процессов ветвления и слияния, действующих на проекте.
Высококачественная PDF-версия этой картинки свободна для скачивания здесь. Распечатайте её и повесьте у себя на стену, чтобы к ней можно было обратиться в любой момент.
Прим. переводчика: статья не новая, ссылка на оригинал уже появлялась на хабре. Этот перевод — для тех, кому английский ещё даётся не так легко (а также для моих коллег, среди которых я занимаюсь пропагандой, хехе). Для автоматизации описанных в статье процедур автор создал проект gitflow, который можно найти на github.