Я використовую git близько року і хотів би використовувати теги, щоб, ну, теги фіксуються в різних версіях. Я знайшов багато інформації про команди, які слід використовувати для роботи з тегами, але те, що я хотів би знати, це навіщо використовувати теги взагалі, якщо я можу просто створити нову гілку під назвою 1.1.0і мені не доведеться затуманювати розум цілим новий набір команд git?
Має бути багато вагомих причин для маркування, а не розгалуження, але я хотів би знати, що це за переваги.
Відповіді:
Теги в основному використовуються для подальшого посилання на конкретну версію проекту, позначаючи комітку. Ви завжди можете використовувати гілки, але якщо сильно змінити версії, ви отримаєте багато невикористаних або рідко використовуваних гілок.
Практично теги - це гілки без гілок у будь-якому випадку, просто додаючи спосіб посилання на конкретну версію проекту, щоб зменшити складність.
Редагувати: Ось хороший спосіб використовувати git, який я використовую для всіх своїх проектів.
Тоді як ви можете створити гілку під назвою "1.0.0" - ви або хтось із правами на виконання зобов'язань також можете просто натиснути на цю гілку (навмисно чи ні) і змінити, що означає 1.0.0.
Ви не можете зробити це з тегом, як тільки ви створите тег - це все; Тег 1.0.0 означає саме це, і його неможливо змінити * .
У цьому головна практична відмінність між тегом і гілкою
* Ви можете видалити та відтворити тег, тим самим змінивши тег, але точно не випадково.
Я схильний використовувати робочий процес, який включає в себе і теги, і гілки. Теги корисні для позначення випущеного коду або помітних побудов розробки. Гілки корисні для відстеження всіх змін, що стосуються конкретної версії.
Ось хороший опис цього типу робочого процесу: http://nvie.com/posts/a-successful-git-branching-model/
Гілка та тег - це одне і те ж (вказівник на фіксацію, ака. "Ref" ), за винятком того, що гілка автоматично переходить до наступної фіксації, поки тег залишається назавжди 1 на одній і тій самій коміті.
Здійснюючи реліз, ви, як правило, бажаєте відзначити "знімок" коду, з якого побудований цей випуск, і ви хочете, щоб він залишався маркованим таким чином, навіть коли ви продовжуєте еволюціонувати код, щоб ви використовували тег.
Якщо ви спробуєте використовувати гілку для цього, це може ненавмисно перейти до іншого коміту, з якого випуск не був побудований.
1 Якщо ви не видалите тег, звичайно.
ПРИМІТКА. Я розумію, що це давнє запитання, але я відчув, що подібність (і одна вирішальна різниця) між гілками та тегами не була чітко проаналізована в інших відповідях настільки чітко, як це могло бути.
git commitоновлення голови перевіреної філії для посилання на нову фіксацію, так, але жодна інша гілка "автоматично" не переходить до наступної фіксації. Вам слід уточнити перший абзац своєї відповіді.
.git\refs\heads, що містить хеш комітів. Самі команди не «пам’ятають», яка галузь їх створила. Наприклад, це відрізняється від Mercurial, наприклад, коли інформація про гілку може бути записана у метадані комітету.
Ви використовуєте теги, щоб відзначати важливі вчинки в історії. "Це було саме те зобов'язання, яке ми використовували для цієї версії в той дощовий четвер, коли сервер збірки зламався". Якщо ви використовуєте гілку замість тегу, ви ніколи не зможете дізнатися, який саме комікс ви використовували. Ви знаєте лише "Ми випустили версію 1.1.0 десь на цій гілці", якщо ви вручну не записуєте точний хеш для цього коміту, саме тому ви в першу чергу використовуєте теги :)
Окрім інших відповідей, ось мої 2 копійки.
Короткий відповідь: Використовуйте теги для версій версій
Довга відповідь: я вважаю, що використання тегів для версії версії конкретніше краще, ніж використання гілок. Якщо вам потрібно оновити реле, просто відключіть тег фіксації, і як тільки ви закінчите роботу над цією гілкою (швидше за все, гілка виправлення), створіть новий тег на чолі цієї нової гілки з новою версією. Потім об'єднайте цю гілку в головну / розробку, оскільки ви дійсно не повинні змінювати версію випуску, якщо це не виправлення, яке, ймовірно, повинно бути об'єднане назад у ваш вихідний код. Потім видаліть цю гілку, оскільки вона більше не потрібна. Якщо вам потрібно застосувати інше виправлення до цієї нової версії, повторіть ті ж дії.
Перегляньте розділ наступної статті, який показує, як об’єднати виправлення з робочим процесом Git автора - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2