Как принудительно удалить удаленную ветку в github?

Log

git log --no-merges --raw --since='2 weeks ago'

Alternatives:

git whatchanged --since='2 weeks ago'
git log --branches --not --remotes

Alternatives:

git log @{u}..
git cherry -v

Показать количество строк, которое добавил/удалил пользователь

git log --author='Your Name Here' --pretty=tformat: --numstat | gawk '{ add += ; subs += ; loc +=  -  } END { printf "added lines: %s removed lines: %s total lines: %s
", add, subs, loc }' -

Alternatives:

git log --author='Your Name Here' --pretty=tformat: --numstat | awk '{ add += ; subs += ; loc +=  -  } END { printf "added lines: %s, removed lines: %s, total lines: %s
", add, subs, loc }' - # on Mac OSX
git log --pretty=oneline --graph --decorate --all

Alternatives:

gitk --all

Коммиты

Так как коммиты являются основой истории версий, не будет лишним узнать о них немного больше.

Команда откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько распространённых аргументов:

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

Несколько советов, к которым стоит прислушаться:

  • Коммитьте часто: вы не сможете откатить изменения, если откатывать не к чему.
  • Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
  • Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось. Здесь подробно расписано, как писать сообщения для коммитов.
  • (Опционально) Не коммитьте незначительные изменения: в большом репозитории множество небольших коммитов могут засорить историю. Хорошим тоном считается делать такие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

Как переключиться на чью-то ветку из удаленного репозитория

Важно понимать, что GIT не позволит вам работать над чужой веткой. Принцип такой – вы создаете локальную копию чужой ветки, и над ней уже работаете

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

git fetch

Теперь можно посмотреть, какие ветки есть в удаленном репозитории:

git branch -v -a

Допустим, там есть ветка dev1. Переключимся на нее, создав локальную ветку с таким же именем:

git checkout -b dev1 origin/dev1

Вообще-то можно было написать проще:

git checkout dev1

Но:

  1. Эта команда сработает только в том случае, если удаленный репозиторий у вас единственный. Если их два, например origin и upstream, то непонятно, на чью ветку переключаться.
  2. Она создаст локальную ветку с точно таким же именем dev1. А в полной версии можно было создать локальную ветку и с другим именем mydev1:
git checkout -b mydev1 origin/dev1

Работа с кодом из репозитория на локальном компьютере

Создание локального репозитория, связанного с удаленным репозиторием

Следующим шагом после создания репозитория на github, называемого далее удаленным репозиторием, является создание локальной копии этого репозитория на своем компьютере. Особенностью git явялется наличие на локальном компьютере полной копии репозитория со всей информацией об истории изменений.

  1. Открываем консольный клиент.
  • На Windows после установки клиента появляется пункт Git Bash в контекстом меню папки. Достаточно перейти в желаемую папку и воспользоваться этим пунктом меню.
  • На Unix системах достаточно открыть терминал и перейти в нужную директорию. При стандартной установке консольного клиента будет доступна команда git без дополнительных усилий.
  1. Выполняем команду . Полную https ссылку на репозиторий для его выкачивания можно также найти на странице самого репозитория на github. После этого в текущей папке появится новая папка с именем , содержащая копию удаленного (remote) репозитория.
  2. Переходим в свежесозданную папку репозитория и настраиваем его:

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

  1. Воспользовавшись командой можно узнать, на какой ветке (branch) репозитория вы сейчас находитесь, какие изменения присутствуют в вашей рабочей копии и другую информацию.Рабочей копией называется совокупность файлов в локальной папке репозитория за исключением служебных файлов.
  2. После внесения каких-либо изменений в рабочую копию их можно закоммитить в локальный репозиторий:
  3. сначала нужная часть изменений подготавливается к коммиту с использованием команды
  4. после чего производится коммит командой
    Использование команды без аргументов откроет текстовый редактор, где надо будет написать комментарий для коммита, коммит обязательно должен иметь комментарий. Другим вариантом задания комментария к коммиту является использование команды
  5. Историю изменений можно посмотреть командой или . Если вся история изменений не умещается на экране, то можно пользоваться клавишами прокрутки на клавиатуре («стрелочки», PgUp, PgDown), выход из режима просмотра изменений осуществляется нажатием клавиши «q».

Загрузка локальных изменений в удаленный репозиторий

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

Branch

git checkout -b branch-name>

Alternatives:

git branch branch-name> && git checkout branch-name>
git branch -m new-branch-name>

Alternatives:

git branch -m  new-branch-name>
git push origin --delete remote-branch-name>

Alternatives:

git push origin :remote-branch-name>

Удаляем ветки, которые уже слиты с master

git branch --merged master | grep -v '^\*' | xargs -n 1 git branch -d

Alternatives:

git branch --merged master | grep -v '^\*\|  master' | xargs -n 1 git branch -d # 
will not delete master if master is not checked out
git branch -a --contains commit-ish>

Alternatives:

git branch --contains commit-ish>

Tags

git push origin :refs/tags/tag-name>

Alternatives:

git push origin :tag-name>
git push -d origin tag-name>
git fetch -p

Alternatives:

git remote prune origin
git fetch origin pull/id>/head:branch-name>

Alternatives:

git pull origin pull/id>/head:branch-name>
git remote

Alternatives:

git remote show

Автокомплит Git-команд в bash

curl http://git.io/vfhol > ~/.git-completion.bash && 
echo '[ -f ~/.git-completion.bash ] && . ~/.git-completion.bash' >> ~/.bashrc

Не отслеживать файл (без удаления)

Удаляет файл из git, сохраняя при этом его локальную копию

git rm --cached file_path>

Alternatives:

git rm --cached -r directory_path>

Обновить все субмодули

git submodule foreach git pull

Alternatives:

git submodule update --init --recursive
git submodule update --remote

Alternatives:

git cherry -v master branch-to-be-merged>

Retrieve the commit hash of the initial revision

 git rev-list --reverse HEAD | head -1

Alternatives:

git rev-list --max-parents=0 HEAD
git log --pretty=oneline | tail -1 | cut -c 1-40
git log --pretty=oneline --reverse | head -1 | cut -c 1-40

Добавление проекта к репо используя subtree

git subtree add --prefix=directory_name>/project_name>
 --squash git@github.com:username>/project_name>.git master

Get latest changes in your repo for a linked project using subtree

git subtree pull --prefix=directory_name>/project_name>
 --squash git@github.com:username>/project_name>.git master

Ignore one file on commit (e.g. Changelog)

git update-index --assume-unchanged Changelog; git commit 
-a; git update-index --no-assume-unchanged Changelog

Поиск коммита с багом при помощи бинарного поиска

git bisect start                    # Search start 
git bisect bad                      # Set point to bad commit 
git bisect good v2.6.13-rc2         # Set point to good commit|tag 
git bisect bad                      # Say current state is bad 
git bisect good                     # Say current state is good 
git bisect reset                    # Finish search 

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

git blame file-name>

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

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

Локальную

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

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

$ git branch -m 

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

$ git branch –m testing test

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

$ git branch -m 

Например, текущая ветка у нас 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

10 ответов

  1. Убедитесь, что вы отметили заменяемую ветку (из ).
  2. Предполагая, что master — это локальная ветвь, которую вы заменяете, а «origin /master» — это удаленная ветвь, в которую вы хотите сбросить:

Это обновит вашу локальную ветку HEAD, чтобы она стала той же ревизией, что и origin /master, и синхронизирует это изменение с индексом и рабочее пространство.

Это так просто, как три шага:

  1. Удалить вашу локальную ветку:
  2. Получить последнюю удаленную ветку:
  3. Восстановите локальную ветвь на основе удаленной:

Заменить все на удаленную ветку; но , только из того же коммита, в котором находится ваша локальная ветвь:

ИЛИ , получите последний из удаленной ветви и замените все:

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

Самый безопасный и наиболее полный способ заменить текущую локальную ветку удаленной:

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

Или как функция bash:

который переименовывает текущую ветвь в нечто вроде replace_master_98d258f.

Вы можете сделать, как сказал @Hugo из @Laurent, или использовать , чтобы удалить коммиты, от которых вы хотите избавиться Если вы знаете, какие из них. Я склонен использовать (где N — число, позволяющее вам манипулировать последними N коммитами) для операций такого типа.

выбранный ответ является абсолютно правильным , однако он не оставил меня с последним коммитом /нажатием …

Так что для меня:

Поскольку я знаю, что хочу временно установить свою ветвь upstream на несколько недель на определенную ветку (такую ​​же, как та, на которую я переключился /выписал ранее и сделал полный сброс)

Итак, ПОСЛЕ сброса

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

Как указано в выбранном объяснении, сброс git — это хорошо.
Но в настоящее время мы часто используем подмодули: репозитории внутри репозиториев. Например, если вы используете ZF3 и jQuery в своем проекте, вы, скорее всего, захотите, чтобы они были клонированы из своих исходных репозиториев.
В таком случае git reset недостаточно.
Нам нужно обновить подмодули до той точной версии, которая определена в нашем репозитории:

это то же самое, что вы (cd) рекурсивно попадете в рабочий каталог каждого подмодуля и запустите:

И это очень отличается от

потому что подмодули указывают не на ветвление, а на фиксацию.

В тех случаях, когда вы вручную извлекаете какую-то ветку для одного или нескольких подмодулей
вы можете запустить

Уродливый, но более простой способ: удалите локальную папку и снова клонируйте удаленный репозиторий.

Ветвление

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

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

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

Стандартные команды:

  • — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент , то команда выведет список всех локальных веток;
  • — переключается на эту ветку. Можно передать опцию , чтобы создать новую ветку перед переключением;
  • — удаляет ветку.

Как наш локальный репозиторий, так и удалённый, могут иметь множество ветвей, поэтому когда вы отслеживаете удалённый репозиторий, на самом деле отслеживается удалённая ветка ( привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязывание к удалённой ветке:

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

В общем, связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды . Чтобы вернуть изменения, используйте .

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

Продвинутое использование: правим историю

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

Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.

Измененяем сообщение коммита/разбиваем коммиты

Для указания коммита, который вы хотите изменить, используется команда . Затем, когда Git будет проводить перемещение, он остановится на этом коммите. После этого вы можете использовать , чтобы изменить сообщение или подготовить забытые файлы. Если вы хотите разделить коммит, после остановки введите (в результате HEAD будет перемещён на один коммит назад и все изменённые в этом коммите файлы перейдут в статус неподготовленных). Затем вы сможете зафиксировать файлы в отдельных коммитах обычным образом.

После завершения редактирования введите .

Перезапись нескольких коммитов

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

Объединение нескольких коммитов

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

Переносим отдельный коммит

Кроме слияния/перемещения всех коммитов в тематической ветке, вас может интересовать только определённый коммит. Допустим, у вас есть локальная ветка drafts, где вы работаете над несколькими потенциальными статьями, но хотите опубликовать только одну из них. Для этого можно использовать команду . Чтобы получить определённые коммиты, из которых мы хотим выбирать, можно использовать .

Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние

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

Теперь, когда вы познакомились с основами ветвления и слияния, возникает вопрос: что можно или нужно делать с этим?
В этом разделе мы разберём некоторые основные рабочие процессы, ставшие возможными благодаря облегчённой процедуре ветвления, которые вы возможно захотите применить в собственном цикле разработки.

Долгоживущие ветки

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

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

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


Рисунок 26. Линейное представление повышения стабильности веток

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


Рисунок 27. Представление диаграммы стабильности веток в виде многоуровневого накопителя

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

Тематические ветки

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

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

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


Рисунок 28. Набор тематических веток

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


Рисунок 29. История после слияния веток и

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

Важно помнить, что во время всех этих манипуляций ветки полностью локальны.
Ветвления и слияния выполняются только в вашем Git репозитории — связь с сервером не требуется. prev | next

prev | next

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

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

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

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

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

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

Note

Для отображение тегов согласно шаблону требуются параметры или

Если вы хотите посмотреть весь список тегов, запуск команды неявно подразумевает это и выводит полный список; использование параметров или в этом случае опционально.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Note

отправляет оба типа тегов

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

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

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

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

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

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

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

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

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

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

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

prev | next

Ссылка на основную публикацию