бранч что это программирование
среда, 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 — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Бранч-стратегии при разработке в 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
Потратить время на политики ветвления стоит по нескольким причинам:
Словарь айтишника: на каком языке они говорят и как их понять
Каждый, кто когда-либо общался с айтишником, не раз переспрашивал его, что именно он имел ввиду. Даже если вы сами работаете в сфере ИТ и приходите в новую компанию, вы наверняка столкнетесь с профессиональным жаргоном и компьютерным сленгом, понять который не удается в первые несколько дней, а то и дольше. Какие-то слова вы возможно уже знаете, о смысле других догадываетесь, но точно мечтаете о том, чтобы вам дали специальный словарь, в котором будет все подробно расписано. Однако, спустя какое-то время вы и сами заговорите на их языке, это неизбежно.
Профессиональный жаргон существует не для того, чтобы испортить русский язык. Он позволяет ускорить устное общение ИТ-специалистов и наладить их взаимопонимание.
Так на каком языке говорят в ИТ-отделе? Ниже мы привели список самых популярных слов.
Баг — расхождение фактического и ожидаемого результата. Интересно, что произошло оно от одной из первых задокументированных ошибок в 1945 году, которая была вызвана жуком (bug), заползшим в шкаф древней ЭВМ и нарушившим ее работу. Пример: «Тестировщик нашел баг в проекте, нужно поправить». Здесь же можно добавить слово Фикс (фиксить, от англ. fix — исправлять). «Всю прошлую неделю фиксил эту странную багу».
Бранч (он же ветка) — полная копия проекта, в которой ведется разработка. В проекте может быть создано несколько веток, что позволяет работать одновременно с разными частями кода. «Посмотри изменения в моем бранче».
Смёржить — в системе контроля версий (git) выполнить слияние (merge) одного бранча в другой. Обычно применяется для обозначения вливания ветки, в которой велась разработка задачи, в основную после проверки другим программистом. Например, «Я смёржил FS-1024».
Конфа — в зависимости от контекста, помимо привычной всем «Конференция», название вики-системы для внутреннего использования (от англ. Confluence), которая помогает создавать единые базы знаний. «Нужно описать эту доработку в конфе, чтобы остальные тоже видели».
Жира (от англ. Jira) — популярная система для ведения задач в ИТ-проектах, которая помогает отслеживать ошибки. «Заведи задачу в жире».
Велосипедить — редкий случай, когда слово образовано не от его английского аналога, а от фразы «Изобретать велосипед», то есть решать, как правило с большим трудом, задачу, для которой уже имеется проверенное решение. «Не надо тут велосипедить, поищи готовое решение».
Ему противоположное — Костылить — решать проблему наспех и непродуманно, самым легким способом, который не учитывает всех возможных последствий и может создать новые проблемы. «Анализировать было некогда, багу быстро закостылили».
Стендап — нет, это не выступление комиков, а ежедневная встреча команды или планерка, на которой сотрудники рассказывают о проделанной работе, обсуждают проблемы и задачи. Примерно для того же самого используется слово Ретро (от слова ретроспектива) — на ИТ-сленге означает обсуждение проделанной работы за конкретный период (неделю, месяц, квартал). «Сегодня стендапа не будет! Обсудим все в конце недели на ретро».
Пыха — скриптовый язык программирования PHP, применяемый для разработки веб-приложений. «Есть ли в офисе специалисты по пыхе?».
Спиннер — элемент интерфейса: вращающаяся анимация на время ожидания. Слово произошло от той самой вращающейся игрушки, которые были популярны несколько лет назад. «Спиннер уже очень долго крутится, но ничего не происходит».
Репа (от англ. Repository) — хранилище, место, где хранятся и поддерживаются какие-либо данные. «Дай мне ссылку на репку, нужно скачать оттуда код».
Моки (от англ. mock up — макет, эскиз) — фиктивные данные, которые используются для отладки взаимодействия в информационных системах. «У нас еще не все готово, поэтому интерфейс частично на моках».
Билдить и деплоить (от англ. to build — собрать и to deploy — развернуть) — выполнять действия, направленные на перевод исходного кода в рабочее состояние на конкретном сервере. «Билдани проект, нужно задеплоить».
Автор статьи — архитектор отдела разработки финансового блока информационных систем CDEK IT.
Основы использования бранчинга для параллельной разработки
Как справедливо заметил 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 — распределённая система управления версиями. Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки.
Ничего не понятно, давай еще раз
Какие такие версии?
Версия — это состояние файла (или нескольких файлов) в какой-то конкретный момент времени. Например, пустой файл (1), тот же файл с каким-то текстом (2) и этот же файл, в котором была исправлена опечатка (3) — три разные версии одного файла, которые были получены последовательной модификацией (изменением) файла.
Системы чего.
Система управления версиями — программа, позволяющая сохранять состояние файлов (те самые версии), возвращаться к ранее сохраненному состоянию, сохранять последовательность изменений внесенных в файлы, отменять или заново применять эти изменения, отслеживать авторство изменений.
Что там с этими версиями делают?
Разделение версий — независимые изменения одного файла.
Версионность на примере текстового файла
Например, у нас есть файл с каким-то текстом (версия этого файла). Файл отправляется на проверку, там обнаруживается и исправляется опечатка (получаем новую версию файла). Независимо от этого в старый (неисправленный) файл дописывается еще что-то (получаем еще одну версию этого файла). Т.е., на данный момент у нас есть два разных файла (две версии одного файла), которые были независимо друг от друга созданы на основе одной общей версии.
Слияние версий — объединение двух и более независимых версий. Для примера выше, слиянием будет объединение двух существующих версий нашего файла в одну — файл, в котором будет и новый текст, и исправленная опечатка.
А при чем тут история?
История разработки — совокупность всех версий файлов, над которыми ведется работа. Историей разработки в данном случае будет список изменений:
добавление изначального текста
добавление нового текста
объединение двух версий файла (при выполнении слияния)
Нелинейная история — история, в которой изменения вносятся не одно за другим последовательно, а может быть внесено несколько независимых изменений на основе одной версии файла (исправление опечатки и добавление нового текста). Т.е. мы создаем две параллельные истории изменений файла.
Немного терминологии
Репозиторий (repository) — совокупность файлов, состояние которых отслеживается, и история их изменений. По факту, репозиторий — это проект, над которым ведется работа, и все изменения в этом проекте. Для отслеживания состояния файла его необходимо добавить в репозиторий.
Коммит (commit) — сохраненное состояние (версия) файлов репозитория.
Ветка (branch) — последовательность коммитов (история изменения состояния репозитория). Каждый коммит в ветке имеет «родителя» (parent commit) — коммит, на основе которого был получен текущий. В репозитории может быть несколько веток (в случаях, когда к одной версии репозитория применяется несколько независимых изменений).
HEAD — указатель на текущий коммит (указатель на состояние, в котором репозиторий находится на данный момент).
Мастер (master, main) — основная ветка репозитория, создается автоматически при создании репозитория.
Мердж (слияние, merge) — объединение двух или более веток. В процессе мерджа изменения с указанной ветки переносятся (копируются) в текущую.
Целевая ветка мерджа — ветка, изменения с которой объединяются с текущей веткой.
База слияния (merge base) — последний общий коммит двух веток.
Мердж коммит (merge commit) — коммит, который создается автоматически по завершению процесса слияния веток. Мердж коммит содержит в себе все изменения целевой ветки мерджа, которые отсутствуют в текущей (все коммиты целевой ветки, которые начиная с базы слияния, но не включая её).
Слияние перемоткой (fast-forward merge) — слияние веток, при котором в текущей ветке отсутствуют новые коммиты (последний коммит текущей ветки является базой слияния). При таком мердже текущая ветка просто переходит в состояние целевой ветки (указатель HEAD переносится на последний коммит целевой ветки). Мердж коммит при этом не создается.
Слияние без перемотки (non fast-forward merge) — слияние, при котором новые коммиты (относительно базы слияния) присутствуют как в текущей, так и в целевой ветках.
В пустом репозитории, в основной ветке, создаем пустой файл, добавляем в репозиторий (теперь git будет отслеживать состояние файла) и коммитим (коммит А).
Добавляем в файл текст, коммитим еще раз (коммит B).
Создаем новую ветку (как бы копируя состояние репозитория), вносим изменения в файл и снова коммитим (коммит С).
Возвращаемся на предыдущую ветку (теперь репозиторий находится в состоянии, которое сохранилось при коммите B, без изменений, которые вносились в новой ветке).
Вносим новые изменения, создаем новый коммит (D).
История изменений при создании новой ветки
После этого новая ветка останется в состоянии С (со своими собственными изменениями), а в основной ветке будут изменения из обеих веток (изменения, внесенные коммитами С и D). Эта ветка перейдет в состояние Е.
Возможна и обратная ситуация, когда изменения из основной ветки вливаются в новую (мердж производится из новой ветки).
При этом мы можем вернуться в новую ветку и продолжить работу в ней (внести новые изменения и создать коммит F).
История изменений после слияния и нового коммита
Мердж конфликт (merge conflict) — ситуация, когда при слиянии веток в один или несколько файлов вносились независимые изменения. В некоторых случаях (например, если изменялись разные, не пересекающиеся части одного файла) git способен самостоятельно решить, как выполнять слияние таких файлов. Если автоматически это сделать не удалось — возникает конфликт. В таком случае необходимо самостоятельно указать, как выполнять слияние конфликтующих версий (решить конфликт, resolve merge conflict). Изменения, внесенные в процессе решения конфликта автоматически попадают в мердж коммит.
Чекаут (checkout) — переход на другое (существующее) состояние репозитория (на другой коммит или ветку). При этом все файлы в репозитории возвращаются в состояние, в котором они находились на момент указанного коммита. Если перед переходом в репозиторий были внесены изменения, которые были добавлены в репозиторий, но не попали в коммит — они будут перенесены «поверх» состояния после перехода. Как и при мердже, git попробует применить эти изменения к новому состоянию автоматически, при неудаче — возникает конфликт и изменения необходимо применить вручную.
Дифф (diff) — разница двух состояний (коммитов, веток, подготовленных или модифицированных файлов).
Трехсторонний дифф (three-way diff) — дифф, возникающий при мердже и решении конфликтов. Является разницей трех состояний: состояния репозитория в текущей ветке, состояния в целевой ветке слияния и общего состояния между этими ветками (состояния в базе слияния).
Черри-пик (cherry-pick) — процесс добавления в текущую ветку одного (или нескольких) коммитов из другой ветки, без необходимости выполнять слияние веток.
Реверт (revert) — отмена внесенных изменений (коммита или группы коммитов). В процессе реверта создается дополнительный коммит, который так же можно отменить при необходимости (вернув репозиторий в изначальное состояние). Реверт мердж коммита позволяет отменить выполненное ранее слияние веток.
Ребейз (rebase) — перенос изменений текущей ветки «поверх» другой ветки. При этом все коммиты текущей ветки, которых нет в целевой, удаляются из текущей и заново создаются в целевой ветке (последовательно применяются к состоянию в целевой ветке). Поскольку ребейз пересоздает коммиты заново и меняет существующую историю, его использование не рекомендуется при командной разработке. Ребейз в ветке, над которой работает несколько человек, может привести к потере чужих изменений и/или невозможности корректно выполнить слияние.
В данном случае коммит Е содержит изменения, которые вносились с момента последнего слияния или создания ветки (с момента коммита В). Т.е. коммит Е содержит в себе изменения из D. При выполнении ребейза git понимает, что эти изменения (E) уже присутствуют в целевой ветке (и окажутся в текущей после ребейза), потому нет необходимости копировать коммит Е, дублируя этим D.
Командная разработка
Наличие удаленного репозитория может быть полезным и при одиночной разработке: оно позволяет синхронизировать состояние проекта на разных компьютерах и просто сохранить проект на внешнем сервере.
Есть два варианта синхронизации изменений:
пулл (pull) — слияние состояния удаленного репозитория и локального (обычно — в отдельной ветке). Пулл может выполняться как для одной и той же ветки (с одинаковым именем), так и для разных. Пулл являет собою обычный мердж, но целевая ветка при этом находится не в том же репозитории, в котором выполняется пулл, а в удаленном. Как следствие, при пулле так же создается мердж коммит, пулл можно отменить (заревертить) и в его процессе может возникнуть мердж конфликт.
пуш (push) — обратный пуллу процесс. При пуше изменения из локального репозитория переносятся в удаленный. Пуш обновляет состояние текущей ветки в удаленном репозитории и не является мерджем (не создает дополнительные коммиты и не может привести к конфликтам). Если в ветке удаленного репозитория присутствуют коммиты, которых нет в локальном репозитории, сигнализируется ошибка о несовпадении истории изменений (non fast-forward merge), пуш выполнить не получится. В таком случае необходимо сначала синхронизировать состояние локального репозитория (получить недостающие коммиты с помощью пулла), и только после этого повторить процесс пуша.
Нередко возникает необходимость обновить информацию о состоянии удаленного репозитория (существующих ветках и коммитах в них) без выполнения слияния (пулла). Такой процесс называется фетчем (fetch). Таким образом, пулл является комбинаций фетча и мерджа: сперва обновляется информация о состоянии целевой ветки в удаленном репозитории, а затем ее изменения вливаются в текущую ветку в локальном репозитории.
основные понятия и термины
простые примеры терминов
применение git’a при командной разработке
некоторые проблемы, которые могут возникать при использовании git’a