В даний час я вчусь користуватися Git, читаючи Pro Git . Зараз я дізнаюся про розгалуження та теги. Моє запитання - коли я повинен використовувати гілку і коли я повинен використовувати тег?

Наприклад, скажіть, що я створюю гілку для версії 1.1 проекту. Коли я закінчую та випускаю цю версію, я повинен залишити відділення для позначення версії випуску? Або я повинен додати тег? Якщо я додаю тег, чи слід видалити гілку версії (якщо припустити, що вона об'єднана в головну чи іншу гілку)?

Коротше кажучи: найкраща практика - це розгалуження, об'єднання часто і завжди синхронізація .

Існує досить чітка умова щодо збереження коду в окремих відділеннях від головного відділення:

1. Ви збираєтесь внести серйозні або руйнівні зміни
2. Ви збираєтесь внести деякі зміни, які можуть бути використані
3. Ви хочете експериментувати над тим, що ви не впевнені, що це спрацює
4. Коли вам скажуть розгалужуватись, в інших може бути щось, що потрібно зробити майстру

Правило великого пальця після розгалуження слід тримати синхронізацію з головною гілкою. Тому що в кінцевому підсумку вам потрібно з’єднати його назад до майстра. Щоб уникнути величезного складного безладу конфліктів при злитті назад, вам слід чинити часто, часто зливатися.

Належні практики

Успішне Гіт розгалуження модель від Vincent Driessen має хороші пропозиції. Якщо ця модель розгалуження сподобалася, ви розглядайте розширення потоку на git . Інші прокоментували потік .

Практика тегів

Як ви вже знаєте, Git дає вам ідентифікатори фіксації, такі як 1.0-2-g1ab3183, але це не теги! Позначення тегів проводиться за допомогою тегу git, і теги, створені за допомогою тегу git, є базою для ідентифікаторів фіксації git опису створює. Іншими словами, в Git ви не тегуєте гілки. Ви позначаєте коміти. Правильно сказати, що тег - це лише позначений вказівник на коміт.

Давайте розглянемо практичний приклад, який це продемонстрував,

                        / - [v1.0]
                       v
---. ---. --- .--- S ---.--- A <- господар
                         \ 
                           \ -.--- B <- тест

Зробимо "S" - фіксацію, вказану тегом "v1.0". Ця фіксація є як у галузі "master", так і у галузі "test". Якщо ви запустите " git опису " поверх комітету "A" (зверху гілки "master"), ви отримаєте щось на кшталт v1.0-2-g9c116e9. Якщо ви запустите "git опису" поверх фіксації "A" (він же гілка "test"), ви отримаєте щось на зразок v1.0-2-g3f55e41, це стосується конфігурації git-опису за замовчуванням. Зауважимо, що цей результат дещо відрізняється. v1.0-2-g9c116e9означає, що ми перебуваємо в команді зі сортованим ідентифікатором SHA-1 9c116e9, 2 комірки після тегу v1.0. Тегу немає v1.0-2!

Якщо ви хочете, щоб ваш тег відображався лише у 'master' гілки, ви можете створити нову фіксацію (наприклад, лише оновити інформацію про версію за замовчуванням / резервну версію в GIT-VERSION-FILE) після точки розгалуження гілки 'test'. Якщо ви позначаєте теги на філії "test", наприклад, "v1.0.3", це буде видно лише з "test".

Список літератури

Я знайшов багато, багато корисних блогів та публікацій, з яких можна навчитися. Однак професійно ілюстровані рідкісні. Таким чином, я хотів би порекомендувати пост - Успішна модель розгалуження Git від @nvie. Я позичив його ілюстрацію :)

Гілка використовується, якщо у вас є дві різні версії сховища одночасно. Тег - це спосіб позначити момент часу у вашому сховищі.

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

Ви хочете видалити гілки, які були об'єднані назад в HEAD [або якусь іншу гілку].