Чи не погана ідея створити тег із такою ж назвою, як видалена гілка?

У мене є проект з моделлю розгалуження git, який приблизно відповідає моделі git-потоку nvie .

Наші відділення релізів названі у форматі SemVer , наприкладv1.5.2

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

Оскільки ми відразу видаляємо гілку випуску, ми використовували той самий ідентифікатор для позначення гілки, наприклад v1.5.2

Ось команди, які ми використаємо для закриття відділення випуску:

$ git checkout master
$ git merge v1.5.2
$ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc"
$ git branch -d v1.5.2
$ git branch -dr origin/v1.5.2
$ git push origin :v1.5.2
$ git push
$ git push --tags

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

git push origin :v1.5.2Команда видалить філія в пульті дистанційного керування, але не видаляє локальну версію філії (якщо він існує) у всіх угодах РЕПО.

Це призводить до неоднозначної посилання при спробі оформлення замовлення v1.5.2в цих репортажах:

$ git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.

Цього можна уникнути, не використовуючи інший синтаксис для гілок, наприклад release-v1.5.2, або v1.5.2-rc?

Або це неминуче, а отже, принципово погана ідея створити тег з такою ж назвою, як видалена гілка?

Якщо ви абсолютно хочете зберегти цю схему іменування, ви можете:

Вирішіть, що вас не хвилюють ці попередження

Тобто, якщо ви задоволені тим, що:

• git checkout <ref>перевірю refs/heads/<ref>більш refs/tags/<ref>(див ГИТ-Checkout )
• інші команди будуть використовувати refs/tags/<ref>більше refs/heads/<ref>(див. gitrevision )

Наприклад, у цьому тестовому сховищі v1.5.2гілка вказує на фіксування B, але v1.5.2тег вказує на здійснення A.

% git log --oneline --decorate
8060f6f (HEAD, v1.5.2, master) commit B
0e69483 (tag: v1.5.2) commit A

git checkout віддає перевагу назвам філій:

% git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Switched to branch 'v1.5.2'
% git log --decorate --oneline -1
8060f6f (HEAD, v1.5.2, master) commit B

але git logвикористовуватиме ім’я тегу:

% git log --decorate --oneline -1 v1.5.2
warning: refname 'v1.5.2' is ambiguous.
0e69483 (tag: v1.5.2) commit A

Це може заплутати.

Навчіть людей видаляти свої локальні гілки, коли вони побачать новий тег

Це може бути важко / незручно в залежності від розміру вашої організації.

Напишіть обгортку навколо "git pull" та "git fetch"

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

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

Ви можете чітко вказати, чи хочете ви відділення чи тег, використовуючи повне ім’я:

 git checkout refs/heads/v1.5.2

або

git checkout refs/tags/v1.5.2