Теги
в Git працюють як закладки для важливих комітів: це зрозуміле людині ім'я, яке відповідає хешу коміту.
Навіщо потрібні теги? Уяви: проєкт дійшов до важливої віхи, скажімо, версії 1.0. Цю точку в історії репозиторію можна позначити на майбутнє. Маючи таке посилання, ти будь-коли легко перемкнеш робоче дерево назад до цього стану. А ще зможеш порівняти поточний код із кодом тієї версії.
Теги також зручні для позначення публічних релізів. Хочеш приклад?
Скажімо, ти розробляєш бібліотеку для конвертації валют і викладаєш її у відкритий доступ. Купа людей починає використовувати твою бібліотеку у своїх проєктах. Слава і визнання!
Згодом ти випускаєш оновлення, які кардинально змінюють API бібліотеки. Усі інші проєкти завантажують нову версію твоєї бібліотеки і підключають її у свій код як є. От тільки їхній власний код ще не оновлений під новий API, тож усі інтеграції миттєво ламаються. І ось половина інтернету у вогні — усе завдяки тобі!
Позначені тегами релізи допомагають уникнути цієї проблеми. Коли ти вперше код, познач його як версію 1.0, і тоді інші проєкти зможуть посилатися саме на цю версію. Якщо потім внесеш кардинальні зміни, познач нову версію як 2.0. Хто користувався старою версією, може спокійно лишатися на ній далі. А хто готовий оновитися, перемкне свої залежності на версію 2.0. Це доволі проста схема, але існує і складніша стратегія версіонування — .
Позначмо останню версію hello.html тегом 1.0.
git tag 1.0Познач останній коміт тегом версії 1.0 командою вище.
Чудово, тег створено. Тепер виведімо список усіх тегів у репозиторії. Для цього запусти без аргументів.
Виведи список усіх тегів у репозиторії командою git tag.
Класно, ось наш тег 1.0!
З посиланнями на коміти й тегами розібралися — тепер поговорімо про гілки.
Проходь курс так, як він і задуманий: маленькими порціями, у сфокусованому лінійному порядку, поступово відкриваючи статті Gitopedia. Будь-коли можна продовжити зі справжнім Git у VS Code/Cursor/Antigravity/Windsurf.
але потрібен вхід