Перевірка тегу Git призводить до "відірваного стану HEAD"

166

Я розробляю сценарій розгортання для свого git проекту, і я тільки почав використовувати теги. Я додав новий тег під назвою v2.0:

git tag -a v2.0 -m "Launching version 2.0"

І я перемістив цей тег до віддаленого сховища

git push --tags

Коли я намагаюся виконати сценарій розгортання та перевірити v2.0тег, я отримаю це повідомлення:

Ви перебуваєте в стані "відокремленої ГОЛА". Ви можете озирнутися, внести експериментальні зміни та здійснити їх, а також можете відмовитись від будь-яких зобов’язань, які ви зробили в цьому стані, не зачіпаючи жодних гілок, виконавши іншу перевірку. Якщо ви хочете створити нову гілку для збереження створених вами зобов’язань, ви можете зробити це (зараз чи пізніше), використовуючи знову -b з командою оформлення замовлення. Приклад: Git checkout -b new_branch_name HEAD зараз о

Це нормально? Сховище знаходиться в кінцівці, тому що якщо я:

git branch

Я отримую цей вихід:

* (no branch)
  master

Вибачте, якщо це очевидно, але я не міг цього зрозуміти.

git deployment git-tag

— Хриз
джерело

Коли ви говорите: "виконати сценарій розгортання та перевірити v2.0" чи виглядає ваш код "git checkout v2.0"? Я намагаюся переробити свій скрипт випуску, і коли я запускаю "git checkout v2.0" зі своєї виробничої машини, я отримую, "error: pathspec 'v2.0' не відповідав жодному файлу, відомому git." Незважаючи на те, що я запускав, "git push origin - теги" на своїй локальній машині, перш ніж робити "git checkout v2.0" на виробництві. Я також спробував запустити, "git pull --tags" та "git fetch --tags" на виробництві до виклику "git checkout v2.0", і це не працює ... Я все одно отримую помилка. Будь-які ідеї?

— Джон Ерк

Я збирався видалити вищевказаний коментар, але потім подумав, що його збереження може допомогти комусь іншому. Я отримував помилку, оскільки під час запуску "git checkout v2.0" у моєму імені TYPO був TYPO. Однак помилка, пов’язана з помилкою друку, є точно такою ж помилкою, яку ви отримаєте, якщо запустите "git checkout v2.0" БЕЗ помилки помилки перед тим, як запустити, "git fetch --tags". Отже, врешті-решт, моя проблема була вирішена шляхом запуску "git fetch --tags" PRIOR to running, "git checkout v2.0" без жодних помилок. Фу!

— Джон Ерк

Добре, так, вам потрібно зробити fetch --tags раніше (або git fetch, який витягне все з віддаленого), щоб git міг перевірити тег. Вибачте, що я щойно побачив ваш коментар.

— Хриз

Відповіді:

429

Гаразд, спершу кілька термінів, трохи спрощених.

В git, a tag(як і багато інших речей) - це те, що називається дерев’яним . Це спосіб посилання на певний момент в історії проекту. Деревами можуть бути тег, фіксація, специфікатор дати, порядковий специфікатор або багато інших речей.

Тепер a branch - це як тег, але є рухомим. Коли ви знаходитесь на гілці та приймаєте на себе зобов’язання, гілка буде перенесена на нове зобов’язання, яке ви зробили, із зазначенням поточної позиції.

Ваш HEADвказівник на гілку, яка вважається "поточною". Зазвичай, коли ви клонуєте сховище, HEADбуде вказувати на те, masterщо в свою чергу вкаже на фіксацію. Коли ви робите щось подібне git checkout experimental, ви перемикаєте HEADна точку на experimentalгілку, що може вказувати на інший фіксатор.

Тепер пояснення.

Коли ви робите a git checkout v2.0, ви переходите до комісії, на яку не вказано a branch. TheHEADТепер «окремі» і не вказує на гілки. Якщо ви вирішите взяти на себе зобов’язання зараз (як це можливо), немає вказівника гілки для оновлення, щоб відстежувати цю комісію. Якщо повернутися до іншого зобов’язання, ви втратите це нове зобов'язання, яке ви зробили. Ось що вам повідомляє повідомлення.

Зазвичай, що ти можеш зробити, це сказати git checkout -b v2.0-fixes v2.0. Це створить новий вказівник гілки на коміті, на яку вказує дерево v2.0(тег у цьому випадку), а потім перемістить ваш HEADвказівник на це. Тепер, якщо ви робите комісії, можна буде відстежувати їх (використовуючи v2.0-fixesгілку), і ви можете працювати так, як зазвичай. Нічого "поганого" в тому, що ви зробили, особливо якщо ви просто хочете поглянути на v2.0код. Якщо ви хочете внести будь-які зміни, які ви хочете відстежувати, вам знадобиться гілка.

Вам слід витратити деякий час на розуміння всієї моделі DAG git. Це напрочуд просто і робить усі команди досить зрозумілими.

— Нуфал Ібрагім
джерело

Добре дякую, мені не потрібно робити ніяких змін у коді, тому я думаю, що це нормально. Мені не потрібно створювати філію. Дуже дякую!

— Хриз

Я втратив перший раз, коли переглянув цю відповідь, але після того, як прочитав документацію про розгалуження Git: http://git-scm.com/book/en/Git-Branching-What-a-Branch-Як це було набагато зрозуміліше .

— марка стилів

Дивовижна відповідь, але чи можу я додати стосовно: "Переключення на інший комітет змусить вас втратити це нове зобов’язання, яке ви зробили". - Ви все одно можете знайти команду git reflog, про яку чудова команда, яку потрібно знати! Якщо не відбулося збирання сміття, втратити зобов’язання, здавалося б, "неможливо".

— Дмитро Міньковський

Невикористані комісії можуть бути втрачені операцією з вивезення сміття.

— Нуфал Ібрагім

URL невірний, оскільки вони змінили макет сторінки.

— jcubic

Так, це нормально. Це тому, що ви перевіряєте одну комісію, у неї немає голови. Тим більше це (рано чи пізно) це не керівник жодної галузі.

Але зазвичай із цією державою проблем немає. Ви можете створити нову гілку з тегу, якщо це робить вас безпечніше :)

— KingCrunch
джерело

Добре, я буду тримати це таким чином ... безпека все одно завищена;)

— Хриз

Як ви прокоментували відповідь на Noufals (це краще, я мушу сказати;)): Поки ви нічого не змінюєте, ви нічого не повинні турбуватися. Однак якщо ви припускаєте , що ви можете щось змінити, ви можете просто створити гілку, оскільки вони є дешевими в git, і ви можете її видалити (і відтворити пізніше тощо).

— KingCrunch