Хорошо, сначала несколько терминов слегка упрощены.
В git tag (как и во многих других вещах) - это то, что называется древовидным . Это способ ссылки на точку в истории проекта. Treeishes может быть тегом, коммитом, спецификатором даты, порядковым спецификатором или многими другими вещами.
Теперь branch похож на тег, но может быть перемещаемым. Когда вы «включаете» ветвь и делаете коммит, ветка перемещается на новый коммит, который вы сделали, что указывает на его текущую позицию.
Ваш HEAD является указателем на ветку, которая считается "текущей". Обычно, когда вы клонируете репозиторий, HEAD будет указывать на master, что, в свою очередь, будет указывать на коммит. Когда вы затем делаете что-то вроде git checkout experimental, вы переключаете HEAD, чтобы указать на ветку experimental, которая может указывать на другой коммит.
Теперь объяснение.
Когда вы делаете git checkout v2.0, вы переключаетесь на коммит, на который не указывает branch. HEAD теперь «отделен» и не указывает на ветку. Если вы решите сделать коммит сейчас (как вы можете), нет указателя ветки для обновления, чтобы отслеживать этот коммит. Переключение на другой коммит заставит вас потерять этот новый коммит, который вы сделали. Это то, что говорится в сообщении.
Обычно вы можете сказать git checkout -b v2.0-fixes v2.0. Это создаст новый указатель ветви при коммите, на который указывает древовидный v2.0 (тег в данном случае), а затем сместит ваш HEAD, чтобы указать на это. Теперь, если вы делаете коммиты, вы сможете отслеживать их (используя ветку v2.0-fixes), и вы можете работать как обычно. Нет ничего «неправильного» в том, что вы сделали, особенно если вы просто хотите взглянуть на код v2.0. Однако, если вы хотите внести какие-либо изменения, которые вы хотите отслеживать, вам понадобится ветвь.
Вы должны потратить некоторое время на понимание всей модели DAG в git. Это на удивление просто и проясняет все команды.