Что такое git branch
Ветвление и слияния
За создание новых веток и слияние их воедино отвечает несколько Git команд.
git branch
Команда git branch — это своего рода «менеджер веток». Она умеет перечислять ваши ветки, создавать новые, удалять и переименовывать их.
Большая часть главы Ветвление в Git посвящена этой команде, она используется повсеместно в этой главе. Впервые команда branch была представлена в разделе Создание новой ветки главы 3, а большинство таких её возможностей как перечисление и удаление веток были разобраны в разделе Управление ветками главы 3.
Наконец, мы разобрались что происходит за кулисами этой команды в разделе Ссылки в Git главы 10.
git checkout
Команда git checkout используется для переключения веток и выгрузки их содержимого в рабочий каталог.
Мы рассмотрели детали взаимосвязи этой команды и git reset в разделе Раскрытие тайн reset главы 7.
Мы исследовали внутренние механизмы этой команды в разделе HEAD главы 10.
git merge
Команда git merge используется для слияния одной или нескольких веток в текущую. Затем она устанавливает указатель текущей ветки на результирующий коммит.
Мы познакомили вас с этой командой в разделе Основы ветвления главы 3. И хотя git merge встречается в этой книге повсеместно, практически все использования имеют вид git merge
с указанием единственной ветки для слияния.
Мы узнали как делать «сплющенные» слияния (когда Git делает слияние в виде нового коммита, без сохранения всей истории работы) в конце раздела Форк публичного проекта.
Мы научились проверять криптографические подписи перед слияниями если ваш проект использует GPG в разделе Подпись коммитов главы 7.
Ну и наконец в разделе Слияние поддеревьев главы 7 мы познакомились со слиянием поддеревьев.
git mergetool
Команда git mergetool просто вызывает внешнюю программу слияний, в случае если у вас возникли проблемы слияния.
Мы вкратце упомянули о ней в разделе Основные конфликты слияния главы 3 и рассказали как настроить свою программу слияния в разделе Внешние программы слияния и сравнения главы 8.
git log
Команда git log используется для просмотра истории коммитов, начиная с самого свежего и уходя к истокам проекта. По умолчанию, она показывает лишь историю текущей ветки, но может быть настроена на вывод истории других, даже нескольких сразу, веток. Также её можно использовать для просмотра различий между ветками на уровне коммитов.
Практически во всех главах книги эта команда используется для демонстрации истории проекта.
git stash
Команда git stash используется для временного сохранения всех незафиксированных изменений с целью очистки рабочего каталога без необходимости фиксировать незавершённую работу в текущей ветке.
Эта команда практически целиком раскрыта в разделе Припрятывание и очистка главы 7.
git tag
Команда git tag используется для задания постоянной метки на какой-либо момент в истории проекта. Обычно она используется для релизов.
Мы познакомились и разобрались с ней в разделе Работа с тегами главы 2 и использовали на практике в разделе Помечайте свои релизы главы 5.
Управление ветками
Теперь, когда вы уже попробовали создавать, объединять и удалять ветки, пора познакомиться с некоторыми инструментами для управления ветками, которые вам пригодятся, когда вы начнёте использовать ветки постоянно.
Команда git branch делает несколько больше, чем просто создаёт и удаляет ветки. При запуске без параметров, вы получите простой список имеющихся у вас веток:
Вы всегда можете указать дополнительный аргумент для вывода той же информации, но относительно указанной ветки предварительно не извлекая и не переходя на неё.
Переименование ветки
Не переименовывайте ветки, которые всё ещё используются другими участниками. Не переименовывайте ветку в master/main/mainline, не прочитав раздел «Изменение имени главной ветки».
Теперь проверим, где мы сейчас находимся:
Теперь старое имя ветки полностью заменено исправленным.
Изменение имени главной ветки
Изменение имени ветки, например master/main/mainline/default, сломает интеграции, службы, вспомогательные утилиты и скрипты сборки, которые использует ваш репозиторий. Прежде чем сделать это, обязательно проконсультируйтесь с коллегами. Также убедитесь, что вы выполнили тщательный поиск в своём репозитории и обновили все ссылки на старое имя ветки в вашем коде или скриптах.
Переименуйте локальную ветку master в main с помощью следующей команды:
В итоге, состояние репозитория становится следующим:
Теперь, для завершения перехода на новую ветку перед вами стоят следующие задачи:
Все проекты, которые зависят от текущего, должны будут обновить свой код и/или конфигурацию.
Обновите конфигурацию всех запускаемых тестов.
Исправьте скрипты сборки и публикации артефактов.
Поправьте настройки репозитория на сервере: задайте новую ветку по умолчанию, обновите правила слияния, а также прочие настройки, которые зависят от имени веток.
Обновите документацию, исправив ссылки, указывающие на старую ветку.
Слейте или отмените запросы на слияние изменений, нацеленные на старую ветку.
Основы ветвления и слияния
Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:
Вы работаете над сайтом.
Вы создаете ветку для новой статьи, которую вы пишете.
Вы работаете в этой ветке.
В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления. Ваши действия:
Переключиться на основную ветку.
Создать ветку для добавления исправления.
После тестирования слить ветку содержащую исправление с основной веткой.
Переключиться назад в ту ветку, где вы пишете статью и продолжить работать.
Основы ветвления
Предположим, вы работаете над проектом и уже имеете несколько коммитов.
Это то же самое что и:
Вы работаете над своим сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на нее ранее ( HEAD указывает на нее).
Но перед тем как сделать это — имейте в виду, что если рабочий каталог либо индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :
С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над проблемой #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в эту ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.
Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку для исправления, в которой будем работать, пока не закончим исправление.
Вы можете прогнать тесты, чтобы убедиться, что ваше исправление делает именно то, что нужно. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :
Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над проблемой #53:
Основы слияния
Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый результирующий снимок трёхстороннего слияния, а затем автоматически делает коммит. Этот особый коммит называют коммитом слияния, так как у него более одного предка.
Теперь, когда изменения слиты, ветка iss53 больше не нужна. Вы можете закрыть задачу в системе отслеживания ошибок и удалить ветку:
Основные конфликты слияния
Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status :
Всё, где есть неразрешённые конфликты слияния, перечисляется как неслитое. В конфликтующие файлы Git добавляет специальные маркеры конфликтов, чтобы вы могли исправить их вручную. В вашем файле появился раздел, выглядящий примерно так:
Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.
Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:
Если вы считаете, что коммит слияния требует дополнительных пояснений — опишите как были разрешены конфликты и почему были применены именно такие изменения, если это не очевидно.
Git branch
В этом документе подробно описывается команда git branch и рассматривается общая модель ветвления в Git. Возможность ветвления доступна в большинстве современных систем контроля версий. Однако эта операция в ряде систем может быть довольно затратной как по времени, так и по объему дискового пространства. В Git ветки — это элемент повседневного процесса разработки. По сути ветки в Git представляют собой указатель на снимок изменений. Если нужно добавить новую возможность или исправить ошибку (незначительную или серьезную), вы создаете новую ветку, в которой будут размещаться эти изменения. Объединить нестабильный код с основной базой кода становится сложнее, к тому же перед слиянием с основной веткой можно очистить историю работы над возможностью.
Git предлагает облегченную реализацию веток по сравнению с другими системами контроля версий. Вместо того чтобы копировать файлы из каталога в каталог, Git хранит ветку в виде ссылки на коммит. Получается, что ветка представляет собой вершину серии коммитов, а не контейнер для коммитов. История ветки распространяется через иерархические отношения с другими коммитами.
Во время чтения помните, что ветки в Git не похожи на ветки в SVN. Ветки в SVN используются только для фиксации периодических крупномасштабных наработок, а ветки в Git являются неотъемлемой частью повседневного рабочего процесса. Далее приводится более подробное описание внутренней архитектуры ветвления в Git.
Порядок действий
Ветка представляет собой отдельное направление разработки. Ветки выступают в качестве абстрактного представления для процесса редактирования/индексации/коммита. Можно рассматривать их как способ запросить новый рабочий каталог, раздел проиндексированных файлов и историю проекта. Новые коммиты записываются в историю текущей ветки, что приводит к образованию развилки в истории проекта.
Распространенные опции
Удаление указанной ветки. Это «безопасная» операция, поскольку Git не позволит удалить ветку, если в ней есть неслитые изменения.
Принудительное удаление указанной ветки, даже если в ней есть неслитые изменения. Эта команда используется, если вы хотите навсегда удалить все коммиты, связанные с определенным направлением разработки.
Вывод списка всех удаленных веток.
Создание веток
Важно понимать, что ветки — это просто указатели на коммиты. Когда вы создаете ветку, Git просто создает новый указатель. Репозиторий при этом никак не изменяется. Допустим, вы начинаете работать с репозиторием, который выглядит так:
Затем вы создаете новую ветку с помощью следующей команды.
История репозитория остается неизменной. Все, что вы получаете, — это новый указатель на текущий коммит:
Создание удаленных веток
До сих пор все эти примеры демонстрировали работу с локальными ветками. Команда git branch работает и с удаленными ветками. Для выполнения операций на удаленных ветках сначала необходимо настроить удаленный репозиторий и добавить его в конфигурацию локального репозитория.
Удаление веток
После того как вы завершите работу в ветке и сольете ее с основной базой кода, эту ветку можно будет удалить без потери истории:
Однако, если ветка не была слита, указанная выше команда выдаст сообщение об ошибке:
Эта команда удаляет ветку независимо от ее состояния и не выдает никаких предупреждений, поэтому используйте ее с осторожностью.
Предыдущие команды удаляют локальную копию ветки, но ветка может сохраниться в удаленных репозиториях. Для удаления ветки из удаленного репозитория выполните следующую команду.
Резюме
По сравнению с другими системами контроля версий, операции с ветками в Git являются экономичными и используются часто. Такая гибкость позволяет эффективно настроить рабочий процесс в Git. Дополнительную информацию о рабочих процессах в Git см. на наших страницах, где подробно обсуждаются: рабочий процесс с функциональными ветками, рабочий процесс Git-flow и рабочий процесс с форками.
Готовы попробовать ветвление?
Ознакомьтесь с этим интерактивным обучающим руководством.
Что такое git branch
Работа с ветками git в терминале, для выполнения домашних заданий
В итоге получается 3 репозитория:
Находясь в ветке master выполняем команду
Второе, выполняем работу по условию задания.
Для этого нам надо проиндексировать изменения.
Командой git status можно посмотреть текущее состояние в ветке, а именно список с названиями изменённых файлов, если они есть, и те, которые ожидают записи и сохранения (обычно они выделены красным цветом).
Из сообщения команды видно, что файл Readme.md модифицирован, но не проиндексирован для коммита.
Коммит сделан, но пока он находится только на локальной машине, а нам надо его отправить в форк, чтобы в дальнейшем предложить Pull Request.
Если дословно, то отправь изменения в форк (origin) в ветку module1-task1 (если такой ветки нет в форке, git создаст её)
Ветка module1-task1: 
Теперь создаем Pull Request из ветки module1-task1 нашего форка в master ветку нашего мастер-репозитория (академии). 
К этому моменту мы имеем:
В удаленный форк мы пушим изменения из локального репозитория, поэтому сперва актуализируем его:
Здесь же опять указываем откуда забирать изменения (из master ветки мастер-репозитория academy)
Если дословно, то отправь изменения в форк (origin) в ветку master.
Всё, на этом работа с заданием завершена ✨ 🧙♂️
Приступая к новому заданию, мы создаем новую ветку и далее по порядку.
Резюмируя шаги, можно написать пошаговую инструкцию перед выполнением нового задания: