Как удалить ветку git локально и удаленно?

Что Такое Ветка Git?

Git — это распределённая система контроля версий (DVCS), в которой все члены команды имеют доступ к полной версии проекта. Её главная задача — помогать в управлении проектам, сделать процесс разработки эффективным, гибким и безопасным.

Ветки — это отдельные линии развития вашего проекта. Они позволяют работать параллельно с master веткой, при этом не влияя на неё. Когда же ваша часть кода готова, вы можете выполнить слияние, или мерж.

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

Ветка не только инкапсулирует изменения, но также гарантирует, что нестабильный код не попадёт к файлам основного проекта. Как только вы закончите обновлять код в ветке, вы сможете смержить изменения в ветку master.

Работа с метками

Как и большинство СКВ, Git имеет возможность помечать определённые моменты в истории как важные.
Как правило, эта функциональность используется для отметки моментов выпуска версий (v1.0, и т.п.).
Метки в Git называются тегами.
В этом разделе вы узнаете, как посмотреть имеющиеся теги, создать новые или удалить существующие, а так же какие их типы существуют в Git.

Просмотр списка меток

Просмотреть список имеющихся тегов в Git можно очень просто.
Достаточно набрать команду (параметры и опциональны):

Данная команда перечисляет теги в алфавитном порядке; порядок их отображения не имеет существенного значения.

Так же можно выполнить поиск тега по шаблону.
Например, репозиторий Git содержит более 500 тегов.
Если вы хотите посмотреть теги выпусков 1.8.5, то выполните следующую команду:

Создание меток

Git использует два основных типа тегов: легковесные и аннотированные.

Легковесный тег — это что-то очень похожее на ветку, которая не изменяется — просто указатель на определённый коммит.

Аннотированные метки

Создание аннотированной метки в Git выполняется легко.
Самый простой способ — это указать при выполнении команды :

Опция задаёт сообщение, которое будет храниться вместе с тегом.
Если не указать сообщение, то Git запустит редактор, чтобы вы смогли его ввести.

С помощью команды вы можете посмотреть данные тега вместе с коммитом:

Здесь приведена информация об авторе тега, дате его создания и аннотирующее сообщение перед информацией о коммите.

Легковесные метки

Легковесная метка — это ещё один способ пометить коммит.
По сути, это контрольная сумма коммита, сохранённая в файл — больше никакой информации не хранится.
Для создания легковесной метки не передавайте опций , и , укажите только название:

На этот раз при выполнении для этого тега вы не увидите дополнительной информации.
Команда просто покажет коммит:

Отложенная расстановка меток

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

Теперь предположим, что вы забыли отметить версию проекта v1.2, которая была там, где находится коммит “updated rakefile”.
Вы можете добавить метку и позже.
Для отметки коммита укажите его контрольную сумму (или её часть) как параметр команды:

Проверим, что коммит отмечен:

Обмен метками

По умолчанию, команда не отправляет теги на удалённые сервера.
После создания теги нужно отправлять явно на удалённый сервер.
Процесс аналогичен отправке веток — достаточно выполнить команду .

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

Теперь, если кто-то склонирует (clone) или выполнит из вашего репозитория, то он получит вдобавок к остальному и ваши метки.

Удаление меток

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

Обратите внимание, что при удалении тега не происходит его удаление с сервера.
Распространены два способа удаление тега из удалённого репозитория. Первый способ — это выполнить команду :

Первый способ — это выполнить команду :

Это следует понимать как обновление удаленного тэга пустым значением, что при водит к его удалению.

Второй способ удалить тег из удалённого репозитория более интуитивный:

Переход на метку

Если вы хотите получить версии файлов, на которые указывает тег, то вы можете сделать для тега.
Однако, это переведёт репозиторий в состояние “detached HEAD”, которое имеет ряд неприятных побочных эффектов.

Если в состоянии “detached HEAD” внести изменения и сделать коммит, то тег не изменится, при этом новый коммит не будет относиться ни к какой из веток, а доступ к нему можно будет получить только по его хэшу.
Поэтому, если вам нужно внести изменения — исправить ошибку в одной из старых версий — скорее всего вам следует создать ветку:

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

prev | next

05 Ничего никогда не теряется

Что же случается с ошибочными коммитами? Оказывается, что коммиты все еще находятся в репозитории. На самом деле, мы все еще можем на них ссылаться. Помните, в начале этого урока мы создали для отмененного коммита тег «oops». Давайте посмотрим на все коммиты.

Результат:

$ git hist --all
* 45fa96b 2011-03-09 | Revert "Oops, we didn't want this commit" (oops) 
* 846b90c 2011-03-09 | Oops, we didn't want this commit 
* fa3c141 2011-03-09 | Added HTML header (HEAD, v1, master) 
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) 
* 43628f7 2011-03-09 | Added h1 tag 
* 911e8c9 2011-03-09 | First Commit 

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

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

Иногда оказывается, что первоначально созданное имя ветки не самое лучшее. Его можно изменить.

Локальную

Если еще не выполнена команда push, то достаточно переименовать локальную ветку.

Чтобы переименовать локальную ветку, выполним команду:

$ git branch -m <old-name> <new-name>

Например, переименуем ветку testing в ветку test:

$ git branch –m testing test

Чтобы переименовать текущую ветку, выполним команду:

$ git branch -m <new-name>

Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:

$ git branch –m subbranch

Удаленную

Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:

$ git push origin :old-name new-name

здесь origin – имя удаленного репозитория (обычно удаленный репозиторий так называется),old-name –  имя ветки локальной ветки,new-name – новое имя ветки в удаленном репозитории.

Например, надо переименовать ветку testing в test:

$ git push origin :testing test

Операции отмены

В любой момент вам может потребоваться что-либо отменить.
Здесь мы рассмотрим несколько основных способов отмены сделанных изменений.
Будьте осторожны, не все операции отмены в свою очередь можно отменить!
Это одна из редких областей Git, где неверными действиями можно необратимо удалить результаты своей работы.

Отмена может потребоваться, если вы сделали коммит слишком рано, например, забыв добавить какие-то файлы или комментарий к коммиту.
Если вы хотите переделать коммит — внесите необходимые изменения, добавьте их в индекс и сделайте коммит ещё раз, указав параметр :

Эта команда использует область подготовки (индекс) для внесения правок в коммит.
Если вы ничего не меняли с момента последнего коммита (например, команда запущена сразу после предыдущего коммита), то снимок состояния останется в точности таким же, а всё что вы сможете изменить — это ваше сообщение к коммиту.

Запустится тот же редактор, только он уже будет содержать сообщение предыдущего коммита.
Вы можете редактировать сообщение как обычно, однако, оно заменит сообщение предыдущего коммита.

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

В итоге получится единый коммит — второй коммит заменит результаты первого.

Note

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

Очевидно, смысл изменения коммитов в добавлении незначительных правок в последние коммиты и, при этом, в избежании засорения истории сообщениями вида “Ой, забыл добавить файл” или “Исправление грамматической ошибки”.

Отмена индексации файла

Следующие два раздела демонстрируют как работать с индексом и изменениями в рабочем каталоге.
Радует, что команда, которой вы определяете состояние этих областей, также подсказывает вам как отменять изменения в них.
Например, вы изменили два файла и хотите добавить их в разные коммиты, но случайно выполнили команду и добавили в индекс оба.
Как исключить из индекса один из них?
Команда напомнит вам:

Прямо под текстом “Changes to be committed” говорится: используйте для исключения из индекса.
Давайте последуем этому совету и отменим индексирование файла :

Команда выглядит несколько странно, но — работает!
Файл изменен, но больше не добавлен в индекс.

На текущий момент этот магический вызов — всё, что вам нужно знать о команде .
Мы рассмотрим в деталях что именно делает и как с её помощью делать действительно интересные вещи в главе Раскрытие тайн reset.

Отмена изменений в файле

Что делать, если вы поняли, что не хотите сохранять свои изменения файла ?
Как можно просто отменить изменения в нём — вернуть к тому состоянию, которое было в последнем коммите (или к начальному после клонирования, или еще как-то полученному)?
Нам повезло, что подсказывает и это тоже.

В выводе команды из последнего примера список изменений выглядит примерно так:

Здесь явно сказано как отменить существующие изменения.
Давайте так и сделаем:

Как видите, откат изменений выполнен.

Important

Важно понимать, что  — опасная команда.
Все локальные изменения в файле пропадут — Git просто заменит его версией из последнего коммита.
Ни в коем случае не используйте эту команду, если вы не уверены, что изменения в файле вам не нужны.

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

Помните, все что попало в коммит почти всегда Git может восстановить.
Можно восстановить даже коммиты из веток, которые были удалены, или коммиты, перезаписанные параметром (см. Восстановление данных).
Но всё, что не было включено в коммит и потеряно — скорее всего, потеряно навсегда.

prev | next