A3.4 Приложение C: Команды Git — Ветвление и слияния
За создание новых веток и слияние их воедино отвечает несколько Git команд.
git branch
Команда git branch — это своего рода «менеджер веток». Она умеет перечислять ваши ветки, создавать новые, удалять и переименовывать их.
Большая часть главы Ветвление в Git посвящена этой команде, она используется повсеместно в этой главе. Впервые команда branch была представлена в разделе Создание новой ветки главы 3, а большинство таких её возможностей как перечисление и удаление веток были разобраны в разделе Управление ветками главы 3.
В разделе Отслеживание веток главы 3 мы показали как использовать сочетание git branch -u для отслеживания веток.
Наконец, мы разобрались что происходит за кулисами этой команды в разделе Ссылки в Git главы 10.
git checkout
Команда git checkout используется для переключения веток и выгрузки их содержимого в рабочий каталог.
Мы познакомились с этой командой в разделе Переключение веток главы 3 вместе с git branch .
В разделе Отслеживание веток главы 3 мы узнали как использовать флаг —track для отслеживания веток.
В разделе Использование команды checkout в конфликтах главы 7 мы использовали эту команду с опцией —conflict=diff3 для разрешения конфликтов заново, в случае если предыдущее решение не подходило по некоторым причинам.
Мы рассмотрели детали взаимосвязи этой команды и git reset в разделе Раскрытие тайн reset главы 7.
Мы исследовали внутренние механизмы этой команды в разделе HEAD главы 10.
git merge
Команда git merge используется для слияния одной или нескольких веток в текущую. Затем она устанавливает указатель текущей ветки на результирующий коммит.
Мы познакомили вас с этой командой в разделе Основы ветвления главы 3. И хотя git merge встречается в этой книге повсеместно, практически все использования имеют вид git merge с указанием единственной ветки для слияния.
Мы узнали как делать «сплющенные» слияния (когда Git делает слияние в виде нового коммита, без сохранения всей истории работы) в конце раздела Форк публичного проекта.
В разделе Продвинутое слияние главы 7 мы глубже разобрались с процессом слияния и этой командой, включая флаги -Xignore-all-whitespace и —abort , используемый для отмены слияния в случае возникновения проблем.
Мы научились проверять криптографические подписи перед слияниями если ваш проект использует GPG в разделе Подпись коммитов главы 7.
Ну и наконец в разделе Слияние поддеревьев главы 7 мы познакомились со слиянием поддеревьев.
git mergetool
Команда git mergetool просто вызывает внешнюю программу слияний, в случае если у вас возникли проблемы слияния.
Мы вкратце упомянули о ней в разделе Основные конфликты слияния главы 3 и рассказали как настроить свою программу слияния в разделе Внешние программы слияния и сравнения главы 8.
git log
Команда git log используется для просмотра истории коммитов, начиная с самого свежего и уходя к истокам проекта. По умолчанию, она показывает лишь историю текущей ветки, но может быть настроена на вывод истории других, даже нескольких сразу, веток. Также её можно использовать для просмотра различий между ветками на уровне коммитов.
Практически во всех главах книги эта команда используется для демонстрации истории проекта.
Мы познакомились c git log и некоторыми её деталями в разделе Просмотр истории коммитов главы 2. Там мы видели использование опций -p и —stat для получения представления об изменениях в каждом коммите, а также —pretty and —oneline для настройки формата вывода этой команды — более полным и подробным или кратким.
В разделе Создание новой ветки главы 3 мы использовали опцию —decorate чтобы отобразить указатели веток на истории коммитов, а также —graph чтобы просматривать историю в виде дерева.
В разделах Небольшая команда главы 5 и Диапазоны коммитов главы 7 мы познакомили вас с синтаксисом branchA..branchB , позволяющем команде git log показывать только коммиты, присутствующие в одной ветке, но отсутствующие в другой. Мы довольно подробно рассматриваем этот вопрос в разделе Диапазоны коммитов.
В разделах История при слиянии и Три точки главы 7 мы рассмотрели синтаксис branchA…branchB и опцию —left-right позволяющие увидеть, что находится в одной или в другой ветке, но не в них обеих сразу. Также в разделе История при слиянии мы рассмотрели опцию —merge , которая может быть полезной при разрешении конфликтов, а также —cc для просмотра конфликтов слияния в истории проекта.
В разделе RefLog-сокращения главы 7 мы использовали опцию -g для вывода git reflog , используя git log .
В разделе Поиск главы 7 мы рассмотрели использование опций -S и -L для поиска событий в истории проекта, например, истории развития какой-либо фичи.
В разделе Подпись коммитов главы 7 мы показали, как использовать опцию —show-signature для отображения строки валидации подписи для каждого коммита в git log .
git stash
Команда git stash используется для временного сохранения всех незафиксированных изменений с целью очистки рабочего каталога без необходимости фиксировать незавершённую работу в текущей ветке.
Эта команда практически целиком раскрыта в разделе Припрятывание и очистка главы 7.
git tag
Команда git tag используется для задания постоянной метки на какой-либо момент в истории проекта. Обычно она используется для релизов.
Мы познакомились и разобрались с ней в разделе Работа с тегами главы 2 и использовали на практике в разделе Помечайте свои релизы главы 5.
Мы научились создавать подписанные с помощью GPG метки, используя флаг -s , и проверять их, используя флаг -v , в разделе Подпись главы 7.
Git branch
В этом документе подробно описывается команда git branch и рассматривается общая модель ветвления в Git. Возможность ветвления доступна в большинстве современных систем контроля версий. Однако эта операция в ряде систем может быть довольно затратной как по времени, так и по объему дискового пространства. В Git ветки — это элемент повседневного процесса разработки. По сути, они представляют собой указатель на снимок изменений. Если нужно добавить новую возможность или исправить баг (незначительный или серьезный), вы создаете новую ветку, в которой будут размещаться эти изменения. Объединить нестабильный код с основной базой кода становится сложнее, к тому же перед слиянием с основной веткой можно очистить историю работы над возможностью.
Связанные материалы
Расширенный журнал Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
На представленной выше схеме показан репозиторий с двумя отдельными направлениями разработки: для небольшой функциональной возможности и для более масштабной. Разработка в отдельных ветках не только позволяет работать над ними параллельно, но и предотвращает попадание сомнительного кода в главную ветку main .
Git предлагает облегченную реализацию веток по сравнению с другими системами контроля версий. Вместо того чтобы копировать файлы из каталога в каталог, Git хранит ветку в виде ссылки на коммит. Получается, что ветка представляет собой вершину серии коммитов, а не контейнер для коммитов. История ветки распространяется через иерархические отношения с другими коммитами.
Во время чтения помните, что ветки в Git не похожи на ветки в SVN. Ветки в SVN используются только для фиксации периодических крупномасштабных наработок, а ветки в Git являются неотъемлемой частью повседневного рабочего процесса. Далее приводится более подробное описание внутренней архитектуры ветвления в Git.
Порядок действий
Ветка представляет собой отдельное направление разработки. Ветки выступают в качестве абстрактного представления для процесса редактирования/индексации/коммита. Можно рассматривать их как способ запросить новый рабочий каталог, раздел проиндексированных файлов и историю проекта. Новые коммиты записываются в историю текущей ветки, что приводит к образованию развилки в истории проекта.
Команда git branch позволяет создавать, просматривать, переименовывать и удалять ветки. Она не дает возможности переключаться между ветками или выполнять слияние разветвленной истории. Именно поэтому команда git branch тесно связана с git checkout и git merge.
О метке
`git branch` – это команда Git для управления ветками. Используйте эту метку для обозначения всех вопросов, связанных с ветками, их созданием, структурой, управлением и удалением.
Общие сведения
git branch – это команда для управления ветками в репозитории Git.
Ветка в Git’е — это просто «скользящий» указатель на один из коммитов. Когда вы создаёте новые коммиты, указатель ветки автоматически сдвигается вперёд, к вновь созданному коммиту.
Ветка, создаваемая первой в новом репозитории, по умолчанию называется master .
Использование
Чтобы создать новую ветку:
git branch
Просмотреть список всех веток в текущем репозитории:
git branch То же, включая удаленные (remote) ветки:
git branch --all Переключиться на другую ветку:
git checkout
Создать новую ветку, указывающую на текущий HEAD:
git branch
То же, плюс переключиться на нее одной командой:
git checkout -b
git branch -d
Взять текущие изменения (после последнего коммита) и создать из них новую ветку:
git stash git stash branch
Часто задаваемые вопросы
- Как переключаться между ветками в git, когда в текущей ветке есть несохраненные изменения?
- Как заменить ветку master другой веткой?
- Как создать ветку в git от произвольного места?
- Как создать копию ветки с удаленного репозитория?
Рекомендуемые к прочтению вопросы
Документация
В русскоязычной документации используются следующие термины:
- branch — ветка
- branching — управление ветками
- local branch — локальная ветка
- remote branch — удаленная ветка
На русском языке:
На английском языке:
Git для начинающих. Урок 7.
Работа с ветками
Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.
Ветки — главная фишка git
Git стал стандартом в системах контроля версий благодаря простой и удобной работе с ветками.
Какие проблемы решают ветки
Представим рабочую ситуацию. Мы сидим и разрабатываем функционал новой большой фичи, например, добавляем на сайт раздел новостей. Уже добавили новые файлы, поменяли стили, поправили разметку, но до завершения еще далеко.
Внезапно прилетает задача — срочно поправить багу в верстке шапки. Мы не можем чинить багу прямо сейчас, в текущем состоянии проекта. У нас много изменений, но работа над большой фичей не завершена — поэтому мешать код новой фичи и код с починкой срочной баги нельзя. Как быть?
Было бы здорово, если бы могли разрабатывать новую фичу независимо от основного кода проекта. То есть взять и зафиксировать рабочее состояние сайта, а делать новый функционал отдельно, не боясь поломать рабочий код. И еще чтобы можно было переключаться между основным кодом (для правки баги) и кодом новой фичи (для продолжения работы над ней)
Когда я не пользовался git, то решал эту проблему созданием архивов проекта. Довел сайт до какого-то рабочего состояния — сделал архив. Реализовал новую фичу — сделал еще один архив. Нужно переключиться на старый код для правки баги — сохранил текущую работу в новый «временный» архив, выбрал старый «стабильный» архив, распаковал, починил там багу, вернулся обратно во «временный» архив.
Схема рабочая, но слишком много суеты и неудобств:
- нужно постоянно создавать архивы с рабочим кодом
- сложно «переключаться» между архивами
- сложно перетаскивать изменения между архивами
- легко что-то напутать или потерять — все мы люди
Все эти проблемы git решает механизмом веток.
Как работают ветки
Представим код проекта в виде дерева. Посередине ствол — это рабочее состояние проекта, тот код, который выложен на боевом сервере. Этот ствол в терминах git называется основной веткой разработки — веткой master. Эта ветка есть всегда в любом проекте. Как только мы клонировали или создали новый репозиторий, мы попали в ветку master. Все, что мы делали на предыдущих уроках, мы делали в мастере.
Когда мы начинаем работать над новым функционалом, мы создаем новую ветку на основе master. Это называется «ответвиться от мастера». После этого мы можем работать, создавать новые файлы, вносить изменения в старые, можем хоть удалить половину проекта — главное, что это будет изолировано от основного мастера. То есть в своей ветке мы можем как угодно ломать проект, основной код при этом не пострадает.
Кроме того мы в любой момент можем переключиться в мастер, например, для правки баги, не боясь потерять изменения в своей ветке с новым функционалом. Починим багу в мастере, выложим правку на боевой сайт и так же легко вернемся к своей ветке и продолжим работать в ней.
Так как git хранит всю историю проекта, то он хранит все коммиты всех веток и со всеми изменениями. То есть вернувшись в свою ветку мы увидим уже сделанные коммиты и можем посмотреть изменения по ним.
Когда мы заканчиваем работать над новым функционалом, то нужно наши изменения перенести в мастер, чтобы залить на боевой сайт. Это называется слить ветку в мастер, или залить в мастер, или смерджить в мастер. При этом после мерджа в мастере оказываются не только наши изменения, но и те, которые были в мастере, но не были в нашей ветке (правка баги в мастере). То есть нам даже не обязательно после правки баги в мастере переносить эти изменения в свою ветку. При мердже git наш новый код «положит» поверх того, что было в мастере, не стирая старый.
Чтобы было нагляднее и понятнее, как это работает, смотрите видео. А в тексте ниже краткое описание команд для работы с ветками.
Ветка master
Еще раз закрепим. Ветка master — это, как правило, основная ветка проекта. Она появляется сразу после клонирования или инициализации репозитория. Есть разные варианты ведения веток, но мы будем считать, что master — наша основная рабочая ветка, от которой ответвляются другие.
Как создать новую ветку
$ git checkout -b news Switched to a new branch 'news'
Так мы создали новую ветку news, имея в виду, что будем разрабатывать в ней блок новостей.
Как переключаться между ветками
Для этого используется команда checkout
$ git checkout news
Обратите внимание, если у вас есть незакоммиченные изменения, то переключиться на другую ветку не получится — git за этим следит
Вот что при этом вы увидите
$ git checkout master error: Your local changes to the following files would be overwritten by checkout: index.html Please, commit your changes or stash them before you can switch branches. Aborting
Поэтому сначала или закоммитьте изменения в ветке, или откатите эти изменения — а уже потом переключайтесь. Это может показаться странным, но так сделано для безопасности, чтобы случайно не потерять код.
Как посмотреть все ветки
$ git branch master * news
Этой командой мы выведем список всех локальных веток. Звездочка у news означает текущую ветку, в которой мы сейчас находимся.
Коммитим в новую ветку
Коммиты в ветку добавляются точно так же, как и раньше. Делаем изменения в файлах, потом git add, потом git commit -m ‘commit message’.
Как запушить новую ветку
Вспомним, как мы пушили раньше
$ git push origin master
Точно так же мы пушим и новую ветку, только вместо master указываем свое название
$ git push origin news
Если такой ветки на сервере нет, то она создастся. Если мы ее уже пушили раньше, то просто отправятся новые коммиты.
Как переименовать ветку
Допустим, мы неудачно выбрали название и хотим его заменить. Находясь в нужной ветке, выполним команды
$ git branch -m block-news
Это переименует текущую ветку news в block-news. Чтобы убедиться, посмотрим список веток
$ git branch * block-news master
Обратите внимание, если мы запушим новую ветку, то на сервере, в github, появится еще одна ветка block-news, и при этом останется старая news. Чтобы не засорять проект, старую ветку нужно удалить как локальную у себя, так и удаленную на сервере.
Как удалить ветку
Удаляется ветка командой git branch -d branch_name. Но здесь могут быть варианты. Рассмотрим, что может пойти не так
$ git branch -d block-news error: Cannot delete the branch 'block-news' which you are currently on.
Здесь просто — мы не можем удалить ветку, потому что в ней находимся. Сначала нужно перелючиться в мастер
$ git checkout master $ git branch -d block-news error: The branch 'block-news' is not fully merged. If you are sure you want to delete it, run 'git branch -D block-news'.
Опять ошибка — здесь git говорит о том, что в удаляемой ветке есть код, который не залит в мастер. То есть при удалении ветки этот код потеряется. Поэтому если мы уверены в своих действиях и ветка действительно не нужна, то вместо флага -d нужен -D
$ git branch -D block-news Deleted branch block-news (was cb38a55).
Теперь удалено без вопросов.
Как работать с ветками в PhpStorm
В правом нижнем углу есть пункт «Git:master». Там пишется название текущей ветки. Чтобы создать новую, нужно кликнуть на этот пункт и выбрать New Branch. Чтобы переключиться, выбрать в списке Local Branches нужную ветку и Checkout. Чтобы удалить или переименовать соотвественно Delete или Rename.
Наглядно это показывается в видеоуроке
Раздел Remote Branches мы рассмотрим в следующем уроке
Что могу посоветовать
- научитесь легко оперировать ветками
- создавайте больше веток
- называйте ветки по общим правилам
- пушьте ветки почаще, их легко потом удалить
Поняв магию веток, мы уже не представим свою работу без git. Любой, даже небольшой проект мы будем начинать с создания репозитория. А работа с ветками будет такой же естественной, как и собственно написание кода. Мне кажется, именно понимание веток превращает git из прикольной тулзы в незаменимый инструмент работы.
И напоследок Киану. Просветление. Назад возврата нет
В следующем уроке мы узнаем, как работать с ветками на сервере
Спасибо за внимание и до встречи!
Все уроки курса
- Вводный урок
- 1. Установка и базовая настройка git
- 2. Создание и клонирование репозитория git
- 3. Делаем первые изменения, git status и git diff
- 4. Коммиты и история коммитов, git commit, git log и git show
- 5. Подробнее об истории коммитов. Путешествие по истории
- 6. Работа с сервером, git push и git pull
- 7. Ветки — главная фишка git, git branch и git checkout
- 8. Работа с ветками на сервере, git fetch
- 9. Слияния или мерджи веток, git merge
- 10. Конфликты и их разрешение
- Платная часть курса. Презентация
- * 11. Работа с gitignore и git exclude
- * 12. Буфер обмена git, git stash
- * 13. Копирование коммитов, git cherry-pick
- * 14. Отмена и редактирование последнего коммита
- * 15. Отмена произвольного коммита, git revert
- 16. Склеивание коммитов, git rebase —interactive и git reflog
- * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
- * 18. Работа с git rebase. Отличия от merge
- * 19. Что такое git push —force и как с ним работать
- * 20. Ищем баги с помощью git, git bisect
- * 21. Как и зачем работать с тегами git
- * 22. Процессы: github flow и git flow
- * 23. Псевдонимы в git
- 24. Мердж-реквесты
- * 25. Форки