Как удалить ветку после merge
Перейти к содержимому

Как удалить ветку после merge

  • автор:

Работа с ветками в Git (git branch)

Инструкция о том, как работать с ветками в Git. Расскажем, как закоммитить изменения и запушить в новую ветку, как удалить ветку или изменить ее — и это не все.

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Введение

Ветвление стало неотъемлемой частью командной разработки, потому что оно дает возможность работать над разными версиями исходного кода. Основной идеей ветвления является отклонение от основного кода и продолжение работы независимо от него. Также это удобно в тестировании отдельного функционала, потому что позволяет работать над новой частью кода, не беспокоясь о поломке чего-то в рабочей версии. В этой инструкции расскажем о том, как работать с ветками в Git.

Основные понятия: о ветке Git и master

Под веткой принято понимать независимую последовательность коммитов в хронологическом порядке. Однако конкретно в Git реализация ветки выполнена как указатель на последний коммит в рассматриваемой ветке. После создания ветки уже новый указатель ссылается на текущий коммит.

Имя основной ветки Git-проекта по умолчанию — master (однако зачастую бывает main, например, в GitHub), она появляется сразу при инициализации репозитория. Эта ветка ничем не отличается от остальных и также ее можно переименовать, но по договоренности master принято считать главной веткой в проекте.

Что делает git branch

Команда git branch — главный инструмент для работы с ветвлением. С ее помощью можно добавлять новые ветки, перечислять и переименовывать существующие и удалять их.

Способы создания веток и переключения между ними

Чтобы в Git добавить ветку мы используем:

$ git branch

После данной операции ветка уже была создана, но вы по-прежнему находитесь в прежней ветке. Если вы планируете переместиться на другую ветку, в том числе только что созданную, необходимо написать checkout:

$ git checkout

Для того чтобы определить, где сейчас находится разработчик, Git использует специальный указатель HEAD, ссылающийся на текущую локальную ветку. В результате checkout HEAD переместится на иную ветку.

Как с помощью git branch создать ветку и перейти в нее

Чаще всего при создании новой ветки git пользователю необходимо сразу же переключиться на нее. В таком случае стоит использовать:

$ git checkout branch

Это будет равносильно:

$ git branch
$ git checkout

И также мы получим тот же результат при использовании git checkout с ключом -b:

$ git checkout -b

Если пользователю нужно получить список определенного множества веток, то тогда можно воспользоваться ключами. Одними из самых распространенных будут:

  • -r — при использовании этого ключа мы получим список удаленных веток,
  • -a — используя этот параметр, в выводе будут удаленные и локальные ветки.

О команде git checkout

При выполнении этой команды Git требуется осуществить определенный порядок действий, чтобы переходить на ветку, которую мы указали. Для этого программа выполняет следующий алгоритм:

Проверка, что указанная нами ветка существует в проекте
Этот этап необходим, так как в ином случае программа не сможет переключиться на ветвь, которая не определена. Для большего понимания нужно вспомнить, что такое ветка в git. Учитываем, что фактически задание ветки — это запись коммита, на который она ссылается. Внутри Git наличие конкретной ветки проверяется наличием одноименного файла в конкретной директории.

Переключение указателя HEAD на новую ветку
Необходимо сместить указатель, чтобы Git понимал, где сейчас идет работа.

Изменение рабочей версии таким образом, чтобы новая ветка ей полностью соответствовала
Сама концепция работы ветвления заключается в том, что в разных ветках находятся разные версии кода, над которыми работа ведется отдельно друг от друга. Тогда необходимо изменить рабочую копию. Git берет последний коммит и восстанавливает все изменения.

После завершения всех перечисленных выше действий можно считать, что мы полностью переключились. Также с помощью checkout можно извлечь отдельный файл (или папку) из другой ветки и получить его, предварительно перейдя в ту ветку, куда вы собираетесь перенести файл. Для этого выполняем:

$ git checkout --

Основы ветвления и слияния

Ветвление позволяет разделять рабочий процесс, оптимизировать тестирование и написание нового кода. Однако после того, как разработчик убедился, что написанный им кусок кода готов и его можно отправить к остальной части итоговой версии, удобно переместить его в основную ветку. Такой подход дает возможность получить к концу разработки проекта целый продукт в одном месте.
Для этого в Git предусмотрено слияние — перенос изменений с одной ветки на другую. Однако сливаемая ветка (под этим определением мы подразумеваем ветку, у которой берем изменения для «вливания» их в другую ветвь) никак не меняется и остается в прежнем состоянии. Такие преобразования мы получаем, применив git merge:

$ git merge

Операция может привести к появлению конфликтов при попытке слить ветки. Это вызвано тем, что изменения удаляют или переписывают информацию в существующих файлах. При попытке некорректного слияния Git останавливает выполнение команды, чтобы вы могли разрешить конфликт.

Также стоит упомянуть о существовании ключей, предназначенных специально для работы с конфликтами:

  • —abort — прерывает слияние и возвращает все к началу
  • —continue — продолжает слияние после разрешения конфликта

Решить конфликт можно двумя способами:

  • Вручную разрешить файловый конфликт. Для этого нужно самим изменить файлы, с которыми возникли проблемы. Мы получим файлы такими, какими и представляли их при попытке слияния.
  • Выбрать более подходящий файл, а от второго отказаться.

Управление ветками с помощью git branch

Эта команда может немного больше, чем просто в git создавать ветки из текущей. Если запустить ее без параметров:

$ git branch

При выполнении этой строки мы получим список существующих веток, где символом * будет отмечена ветка, где вы сейчас находитесь. Это может выглядеть так:

 first_branch * master second_branch

С помощью параметра -v можно получить последний сохраненный коммит в каждой ветке.

$ git branch -v first_branch 8fa301b Fix math * master 225cc2d Merge branch 'first_branch' second_branch c56ee12 Refactor code style

Так же существуют опции —merged и —no-merged, с помощью которых можно отфильтровать полученную последовательность веток. То есть мы получим список ответвлений, которые уже были слиты, или, наоборот, ветки, которые еще не прошли через слияние с другими. Выведем ветки, которые уже были слиты с текущей:

$ git branch --merged first_branch * master

Как закоммитить изменения в новую ветку

После создания новой ветки, перехода в нее и совершения всех запланированных преобразований, нужно сделать коммит в эту же ветку, чтобы сохранить все изменения. Команды для выполнения этих действий ничем не отличаются от команд для создания коммитов в ветке мастер.

$ git add
$ git commit -m ''

После выполнения последовательности этих команд мы закоммитили изменения в нужной версии программы.

Как запушить в новую ветку

Если мы хотим запушить нашу ветку, то для этого нужно написать:

$ git push origin

Теперь ветка запушена. Если до этого мы уже пушили ее, то произойдет отправка новых коммитов.
В отличии от команды git checkout, при выполнении пуша нет проверки на существование указанной ветки. Это будет значить, что при написании несуществующей ветки git создаст ее автоматически.

Как переименовать ветку

В процессе разработки могут возникнуть ситуации, когда человек хочет по-другому называть уже созданную ветку. Это может быть связано с разными причинами (например, разрабатываемый в данной версии функционал не соответствует названию). Чтобы переименовать ветку применяем:

$ git branch -m

Однако здесь нужно быть аккуратными, чтобы не перегрузить проект ненужными ветками. Если запушить переименованную ветку, то на сервере появится ветка с новым именем, но и ветка со старым названием тоже останется. Чтобы избежать такой проблемы, необходимо удалить ветку локально и на сервере.

Как удалить ветку

Удаление веток не такой простой процесс, как может показаться. Можно случайно удалить несохраненные изменения в исходном коде, что приведет к нежелательным последствиям. Поэтому здесь нужно действовать осторожно. С операцией удаления над ветками справляется уже привычная команда git branch с параметром -d:

$ git branch -d

Для корректного удаления нужно помнить несколько правил, чтобы не получить ошибки:

  • Нельзя удалить ветку, в которой вы находитесь. Git выкинет ошибку и не произведет удаление. Следовательно, нужно перейти на другую ветку.
  • Git не позволит удалить ветку, у которой есть несохраненные изменения. Так мы избегаем ситуации, когда часть написанного кода будет безвозвратно утеряна. Если же мы уверены, что изменения в этой версии не нужны и их можно смело удалять, то вместо флага -d используем -D:
$ git branch -D

Соблюдая все условия, нам удастся удалить указанную ветвь.

Работа с ветками на практике

В инструментах для разработки на языках часто есть встроенный функционал, позволяющий работать напрямую с Git. Например, в таких средах разработки как IntelliJ IDEA, PyCharm, PhpStorm, CLine, Rider очень удобно и понятно, как правильно оперировать с разными ветками. Для примера разберем работу в одной из таких сред.

Как работать с ветками в PhpStorm

интерфейс для работы с ветками

Справа в нижнем углу расположены вкладки для работы с Git, где и происходит вся настройка ветвления. На этой панели расположено название текущей ветки. При желании создать новую нужно нажать на этот пункт и выбрать New Branch. Для смены ветки — выбрать из списка искомую и кликнуть на Checkout. Для удаления и переименования предусмотрены кнопки Delete и Rename соответственно.

Работа в специальном приложении почти ничем не отличается от работы в консоли, поэтому все полученные знания можно применять независимо от выбранного способа.

Получение информации о состоянии веток

Как просмотреть состояния файлов ветки

Отметим, что при переходе на другую версию, незакоммиченные изменения перенесутся на ветку, куда мы перейдем. Поэтому перед переключением необходимо убедиться, что изменения в текущей ветки уже закоммичены. Для этого подходит git status:

$ git status

Выполнение этой операции позволит просмотреть файлы, расположенные в ветке, где мы находимся. Как раз с помощью нее можно отслеживать незакоммиченные изменения, чтобы случайно не перенести их в другое место. Пустой вывод этой команды показывает то, что в ветке не присутствуют измененные файлы и мы можем без опасений продолжать с ней работу. А иначе необходимо закоммитить все нужные исправления.

Как просмотреть истории коммитов ветки

Неоднократно в процессе разработки нужно посмотреть на журнал изменений: для отслеживания развития проекта или для определения коммита, к которому следует вернуться. В таких ситуациях выручает команда git log:

$ git log --

У данной команды есть множество ключей, используя которые можно получить более конкретную информацию:

  • — (равноценно -n= ) — показывает последние n коммитов,
  • —pretty= (доступные такие значения, как oneline, short, medium, full и другие) ****— форматированный вывод истории,
  • -p — выводятся изменения, содержащиеся в коммите,
  • —graph — представляет дерево взаимосвязей коммитов в виде ASCII-графа — такой метод использования позволяет получить графическое представление ветвей прямо в консоли,
  • —all — на выходе мы получаем историю всех коммитов для всех существующих веток,
  • —decorate — показывает, на что ссылаются указатели.

Если нам нужно посмотреть историю для конкретной ветви, то поможет выполнение:

$ git log ..

Структура веток в Git представлена в виде графа. Когда мы получаем коммиты определенной ветки, передвигаясь «вверх» по графу, мы должны остановиться в тот момент, когда дойдем до коммита, который будет меньше указателя родителя ветки. При выполнении этого условия когда ветка, чья история коммитов нас интересует, добирается до своего родителя, вывод прекращается, и мы получаем корректный ответ.

Как просмотреть различия между коммитами

Достаточно часто в ходе разработки какого-либо продукта у разработчика может возникнуть потребность посмотреть разницу между двумя коммитами, прежде чем заливать что-то. Для этого существует git diff:

$ git diff

Для этой операции также предусмотрены несколько ключей:

  • —diff-filter= — с помощью этого параметра, изменяя значения меток, можно задать, обновления между какими файлами мы хотим увидеть. Рассмотрим некоторые возможные значения меток:
    • D — покажет удаленные файлы,
    • M — мы получим файлы, модифицированные после последнего коммита.

    Заключение

    Git обладает множеством преимуществ по сравнению с другими системами контроля версий как раз из-за легковесной работы с ветвлением. Такая гибкость помогает максимально оптимизировать процесс разработки. А само ветвление сильно упрощает разработку проекта. Ветки обеспечивают безопасный совместный доступ к коду для разных людей. Ведь именно они дают возможность пластично и изящно работать над созданием нового продукта.

    Как установить Git на Windows

    Удаление и восстановление ветвей в запросе на вытягивание

    Если у вас есть доступ на запись к репозиторию, можно удалить ветви, связанные с закрытыми или объединенными запросами на вытягивание. Невозможно удалить ветви, которые связаны с открытыми запросами на вытягивание.

    Deleting a branch used for a pull request

    You can delete a branch that is associated with a pull request if the pull request has been merged or closed and there are no other open pull requests referencing the branch. For information on closing branches that are not associated with pull requests, see «Creating and deleting branches within your repository.»

    1. On GitHub.com, navigate to the main page of the repository.
    2. Under your repository name, click

    Screenshot of the main page of a repository. In the horizontal navigation bar, a tab, labeled

    Pull requests.

    Screenshot of the

    To see a list of closed pull requests, click Closed.

    Restoring a deleted branch

    You can restore the head branch of a closed pull request.

    1. On GitHub.com, navigate to the main page of the repository.
    2. Under your repository name, click

    Screenshot of the main page of a repository. In the horizontal navigation bar, a tab, labeled

    Pull requests.

    Screenshot of the

    To see a list of closed pull requests, click Closed.

    Further reading

    • «Creating and deleting branches within your repository»
    • «Managing the automatic deletion of branches»

    Как удалить ветку после merge?

    У меня было 2 ветки: master и feature. Я вёл их параллельно и потом решил смержить feature-ветку в master-ветку. После успешного мерджа консоль визуально показывала 2 ветки поэтому я решил удалить ветку feature. Удаление прошло успешно, но после этого консоль всё равно показывает две ветки.

    Скажите пожалуйста, можно ли как-нибудь избавиться от feature чтобы не загромождать вид? Теоретически возможна ситуация когда придётся вести одновременно 20 feature веток и выглядеть это будет неудобно, если не чистить.

    Ниже код, в который поясняет вопрос:

    Switched to branch 'master' md@md ~/.MINT18/code/git/merge $ git hist * 5a8014e 2021-03-08 | m8 (HEAD -> master) [kalinin] |\ | * 4220d18 2021-03-08 | f7 (feature) [kalinin] | * 93062a3 2021-03-08 | f6 [kalinin] | * 02efa31 2021-03-08 | f4 [kalinin] | * 5bde83a 2021-03-08 | f3 [kalinin] * | b417e0e 2021-03-08 | m5 [kalinin] |/ * a3a8961 2021-03-08 | m2 [kalinin] * ede090f 2021-03-08 | m1 [kalinin] md@md ~/.MINT18/code/git/merge $ git br -a feature * master md@md ~/.MINT18/code/git/merge $ git br -D feature Deleted branch feature (was 4220d18). md@md ~/.MINT18/code/git/merge $ git br * master md@md ~/.MINT18/code/git/merge $ git hist * 5a8014e 2021-03-08 | m8 (HEAD -> master) [kalinin] |\ | * 4220d18 2021-03-08 | f7 [kalinin] | * 93062a3 2021-03-08 | f6 [kalinin] | * 02efa31 2021-03-08 | f4 [kalinin] | * 5bde83a 2021-03-08 | f3 [kalinin] * | b417e0e 2021-03-08 | m5 [kalinin] |/ * a3a8961 2021-03-08 | m2 [kalinin] * ede090f 2021-03-08 | m1 [kalinin] 

    Как удалить ветку после merge

    Зачем писать в консоли одно и то же, если можно забиндить команду с текстомым инпутом на кобинацию клавиш.

    Git: Как сделать rebase на staging (вместо подмерживания staging)

    :exclamation: Важно: кейс описывает ситуацию, когда вы работаете в своей ветке и уже пушили коммиты в удалённую ветку, а вместо привычного подмерживания staging/master решили сделать ребейз, например для фикса конфликтов или фикса инспекций 1. Переключаемся на ветку задачи: git checkout 2. Делаем pull с rebase-ом, (подтягиваем свежий стейдж и переносим свои коммиты на него): git pull —rebase origin staging 3. Если прошло без конфликтов, то делаем форспуш в свою удалённую ветку:

    Git: Интерактивный ребейз и как дропнуть или объединить коммиты

    :exclamation: Важно: кейс может быть частым, если вы не договорились с разработчиками о том, что форспушить в общую ветку нельзя. В реальности: Вы открываете свой PR в GitHub, а там вперемешку с вашими коммитами — коммиты разработчика. Обычно они там появляются после того, как разработчик форспушит что-то в ветку, от которыой вы ответвились. Что делать: Левые коммиты нужно либо дропнуть либо обновить ветку, чтобы вашим ревьюверам не мешал код фронта/бэка (ну и не только). Для дропа или объединения коммитов делаем интерактивный ребейз, т.е. git rebase -i: 1. Переключаемся на свою ветку (с последними изменениями):

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *