Что такое branching git
September 04, 2014
Продолжаю совместно с вами постепенно изучать магию Git\GitHub.
Инициализация Git-репозитория
В браузере примерный вид странички будет выглядеть таким образом:
В системе Git (как уже упоминалось ранее) имеется механизм ветвления (branches). Попробую на словах объяснить, что он из себя представляет.
Допустим, в моем текущем проекте, у которого имеются два файла, нужно внести кардинальные изменения. Причем, изменения такого рода, что они могут нарушить работу уже существующего проекта. Чтобы обезопасить себя (подстраховать), создаю точную копию существующего проекта и перехожу в нее для дальнейшей работы.
Строка On branch second говорит сама за себя.
Отлично! Теперь давайте я внесу некоторые изменения в файлы index.html и style.css и мы вместе посмотрим на результат в окне браузера. Изменения будут касаться добавления блока-обертки, еще нескольких параграфов и другой легкой стилизации.
Если я снова вернусь в ветку second и запущу команду просмотра логов Git, то коммитов окажется больше:
Мне кажется, уже сейчас должно быть понятно, что такое ветви (branches) в Git и для чего они предназначены. На самом деле это действительно очень просто.
При слиянии ветвей зачастую может возникнуть ситуация, когда происходит конфликт между двумя ветвями. Рассмотрение вопроса решения конфликтов при слиянии не рассматривается мною, так как на данный момент еще не освоил этот вопрос до конца.
Система Git имеет в своем составе возможность графического представления ветвления в репозитории. Причем, такое представление можно сделать даже в консоли, с помощью псевдографики.
Это можно сделать, набрав в консоли команду:
На Stack Overflow я нашел примеры красивых изображений консоли с псевдографическим выводом команды git log :
Выполняется это командой:
Посмотрим на вывод команды git hist :
Git. Урок 3.
Ветвление. Создание, переключение и удаление веток. Команды: branch, checkout, status, log, diff.
1. Что такое ветка.
2. Зачем нужны ветки.
3. Создание новых веток.
4. Просмотр списка веток.
5. Переключение между ветками.
6. Просмотр состояния ветки. Команды: git status, git log, git diff.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
6.3. Просмотр различий между коммитами. Команда git diff.
7. Удаление веток.
Дадим два определения ветки: на логическом и физическом уровнях.
1. Логический уровень.
С точки зрения логики, ветка – это последовательность коммитов. Чтобы проще было понять, что такое ветка, рассматривайте ее как некоторую временную шкалу. Коммиты в ней – снимки интересных моментов, идущие друг за другом в хронологической последовательности. Рисунок ниже поможет вам в интуитивном представлении.
2. Физический уровень
На физическом уровне, то есть с точки зрения внутренней реализации Git, ветка – это ссылка на последний коммит в этой ветке. Картинка ниже поможет вам понять, что к чему.
Преимущество веток в их независимости. Вы можете вносить изменения в файлы в одной ветке, например, пробовать новую функцию, и они никак не скажутся на файлах в другой ветке. Изначально в репозитории одна ветка, но позже мы рассмотрим, как создавать другие.
На самом деле, вначале, когда мы делаем свой первый коммит, Git автоматически создает основную ветку. Вы можете помнить, что ее имя по умолчанию «main» мы задавали в настройках Git в предыдущем уроке. Каждый раз, когда мы создаем новый коммит, Git автоматически перемещает указатель main на последний коммит. Тем не менее, в следующем уроке мы узнаем, как перемещать указатель ветки между коммитами самостоятельно.
Пока мы разбирались, что такое ветка, у вас мог возникнуть вопрос: зачем нужны такие сложности, ведь можно просто делать коммиты и откатывать изменения, когда нужно.
Дело в том, что Git – универсальная система контроля версий: она подходит и большим командам крупных корпораций, и индивидуальным разработчикам для их личных проектов.
Если вы работаете один – скорее всего вы будете редко использовать ветки, но если вы работаете в большой компании, без веток вам не обойтись.
Итак, чаще всего ветки используются в следующих случаях.
Способ 1. Команды git branch + git checkout
Команда git branch
На самом деле, git branch – очень мощная команда, которая умеет много всего. Сейчас мы рассматриваем ее как инструмент для создания веток. Ниже мы рассмотрим еще некоторые способы ее применения.
Команда git checkout
40 шестнадцатеричных цифр в файле выше и есть хэш последнего коммита, на который указывает новосозданная ветка.
С помощью команд git branch и git checkout вы можете создать неограниченное количество веток и переключаться между ними по мере необходимости. Обычно если ветка вам больше не нужна, ее сливают с основной и удаляют. Тема слияния веток заслуживает отдельного урока, поэтому про это мы поговорим в следующий раз, а удаление веток рассмотрим чуть ниже.
Команда git branch
# Теперь выведем только локальные ветки
$ git branch
* develop
feature
main
Теперь, когда мы поняли, как можно узнать имена веток в репозитории, давайте научимся переключаться между ними.
Команда git checkout
Этот маленький фокус позволит вам сэкономить время, особенно, если вы часто переключаетесь между ветками.
Шаг 1. Проверка существования ветки
Нужен этот этап, чтобы случайно не переключиться на ветку, которой не существует. Чтобы понять, как происходит этот процесс, нужно сделать небольшое отступление и рассказать, как вообще Git хранит информацию о существующих ветках.
Шаг 2. Переключение HEAD на нужную ветку
Шаг 3. Изменение рабочей копии
У внимательного читателя мог возникнуть вопрос: почему файлы в рабочей копии подгружаются именно из последнего коммита ветки? Что если до переключения с данной ветки, в ней были какие-то изменения, еще не добавленные в коммит? Что с ними будет? Ответ довольно прост. Согласно трем шагам, указанным выше, Git просто проигнорирует все такие файлы. То есть они останутся в вашей рабочей копии в том же состоянии, в котором и были до этого. Как правило, такое поведение очень неудобно, поскольку позволяет легко запутаться в структуре собственного проекта. Представьте: у вас два параллельных релиза, а вы, переключаясь между ветками, случайно занесли файлы одного релиза в ветку другого.
6.1. Просмотр состояния файлов ветки. Команда git status.
6.2. Просмотр истории коммитов ветки. Команда git log.
Команда git log
-p
Показывает изменения, сделанные в данном коммите.
—graph
Рисует ASCII-граф взаимосвязи коммитов.
—all
Выводит историю всех имеющихся коммитов на всех ветках.
adding complex algebra project
commit 603def20e5da2d512da2852011eb5be3fa156940 (origin/main, origin/HEAD)
Author: smartiqa
Date: Fri Dec 4 02:00:41 2020 +0300
В описании команды git log выше сказано, что в зависимости от ситуации, она может вывести полную историю репозитория, или же только историю некоторых коммитов. Давайте разбираться, как работает Git при выводе истории.
Общее правило, которым руководствуется Git при выводе истории, такое: иди по предкам коммитов, пока они не закончатся. Иногда это бывает удобно, иногда – нет.
Давайте разберемся, что делать, если мы хотим просмотреть историю коммитов только внутри какой-то конкретной ветки. То есть историю от момента создания ветки, до последнего коммита в ней. В этом случае нужно сделать следующее:
Ветвление и слияния
За создание новых веток и слияние их воедино отвечает несколько 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: Где и Как Использовать Git Branch
Что Такое Git Branch
Git branching, или ветвление Git – отличный способ работать над нашим приложением и одновременно отслеживать его версии. Ветвь разработки – это бифуркация состояния кода, что создает новый путь для его эволюции. Вы можете генерировать разные ветки Git, которые будут существовать параллельно к главной ветке. Таким образом, вы сможете упорядоченно и точно включать новые функции в ваш код.
Использование Git Branches имеет несколько преимуществ. Тем не менее, мы хотим подчеркнуть следующие два:
Каждый разработчик может использовать собственные модели ветвления, исходя из своего опыта.
Где и как использовать Git Branch
Работать с Git branches довольно просто, это видно из самих команд. Но, как и в большинстве других случаев, чем больше у вас веток, тем сложнее управлять ими.
В любом проекте Git мы можем просмотреть все ветви, введя следующую команду в командной строке:
Если вы не создали ни одной Git branch, в терминале не будет выходных данных. Создать ветку действительно просто:
Затем нам нужно перейти в новую ветку Git, которую вы только что создали. Для этого мы запустим следующую команду:
Результат сообщит нам, что мы перешли в новую ветку. Мы назвали её тестовой, так что мы увидим следующее сообщение:
Теперь в этой новой ветви разработки мы можем создать столько модификаций кода, сколько захотим, без необходимости что-либо менять в основной Git branch. Как мы видим, это поддерживает готовность программы к добавлению новых частей кода.
Если мы запустим команду для повторного вывода списка ветвей, мы увидим, что добавлена новая ветка и что мы находимся в ней.
Есть кое-что, о чём мы должны помнить, создавая новую ветку разработки. Во-первых, мы должны сделать commit в основную ветку, чтобы Git понял, что это master branch. Если мы этого не сделаем, мы получим ошибку. Итак, сначала сделайте commit, а затем создавайте ветки разработки.
Если мы хотим удалить ветку из Git, мы можем сделать это с помощью следующей команды:
Однако, мы не можем находиться в той ветке, которую хотим удалить. Сначала мы перемещаемся в главную ветку и уже оттуда удаляем только что созданную:
Наконец, наступил момент, когда мы внесли много изменений в ветку разработки и она превратилась в стабильную, поэтому мы хотим связать её с другой веткой разработки. Для этого и существует команда слияния ( merge ).
Сначала найдите ветку разработки, к которой должна быть присоединена другая ветка. Например, мы хоти прикрепить тестовую ветвь к основной ветке – master branch. Для этого мы должны перейти в master branch и осуществить merge с помощью команды:
Как видите, основные функции ветки Git довольно просты. Вам просто нужно знать основы и стараться поддерживать порядок в своём проекте.
Выводы
Умение использовать Git branch, является очень важным, особенно, если вы работаете в команде. Организовывайте свой код в разных ветках Git с умом.
В этой статье мы научили вас основам работы с ветками Git.
Ольга уже около пяти лет работает менеджером в сфере IT. Написание технических заданий и инструкций — одна из её главных обязанностей. Её хобби — узнавать что-то новое и создавать интересные и полезные статьи о современных технологиях, веб-разработке, языках программирования и многом другом.
Гит-словарик для начинающих программистов
Мёржим бранчи и коммитим реквесты
Мы часто упоминаем 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)
Чтобы отправить данные из своего проекта на сервер, используют gut push. Для этого программист указывает имя ветки, в которую хочет отправить свой код, а сервер их принимает, проверяет и добавляет к себе.
Иногда бывает так, что сервер отказывается это сделать, потому что у программиста на компьютере была неактуальная ветка. За то время, пока он писал свои правки, другие программисты сделали несколько изменений, закоммитили их у себя и отправили на сервер. Получилось, что у одних эта ветка осталась свежей и актуальной, а у других она устарела. Чтобы не принимать запросы из устаревших веток, гитхаб просит сначала обновить данные у себя на комьютере с помощью git pull.
Пулл работает просто: он скачивает с сервера актуальную версию ветки и добавляет код оттуда вам на компьютер. Иногда этот код вступает в противоречие с тем, что уже успел сделать программист, и тогда возникает конфликт — нужно принять решение, какая версия одинакового кода останется в проекте, а что нужно будет убрать.
Чем коммит отличается от пуша
Коммит — это когда вы фиксируете изменения в проекте, как бы подводите итог своей работе.
Пуш — это когда вы отправляете сделанную работу туда, где хранится копия вашего кода.
Получается, последовательность действий такая:
Что дальше
Чтобы все эти бранчи и реквесты стали понятнее, в следующий раз сделаем вот что: заведём учебный проект на Гитхабе и будем работать с ним так, как делают настоящие программисты.