Я бачив, як кілька людей тут задавали одне і те ж питання, але, здається, жодна їхня порада не стосується мене. Я отримую попередження, яке є в назві цього, але у мене немає жодних тегів з назвою "master". Це результат git branch -a:
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
Будь-яка ідея, що тут може піти не так? Я використовую git лише кілька місяців, тому мене здебільшого просто турбує, що ця двозначність може зіпсувати репо в майбутньому.
git checkout heads/masterповинен працювати (без попередження)
git show-ref.
git show-ref- це купа речей, які сюди не поміщаються. Я вважаю, що може бути доречним, що є два рядки, які закінчуються на "master": refs / remotes / origin / master, refs / heads / master
Відповіді:
Для мене я відстежив джерело цього попередження набагато раніше, коли неправильно видав команду "update-ref". Якщо ви забули вказати повний шлях refs / heads / mybranchname у першому аргументі, тоді створюється файл .git / mybranchname, який згодом призводить до цього попередження при спробі перейти на цю гілку.
Це вирішується простим видаленням .git / mybranchname, наприклад:
rm .git/master
І для довідки, правильною формою команди update-ref є:
git update-ref refs/heads/mybranchname mytargetbranch
Не забудьте про частину "refs / heads"!
Крім того, мій найпоширеніший варіант використання для update-ref - це просто ручне переміщення гілки, щоб вказати на інший коміт, що я знайшов простіший синтаксис:
git branch -f myBranchToMove destinationBranchOrHash
Мені цей синтаксис простіший, тому що він не вимагає використання схильного до помилок кваліфікатора refs / heads.
git update-ref -d masterтакож працює, як тільки ви зрозумієте, що команда update-ref створила дублікат ref.
Як детально описано в " Git: refname ' master' є неоднозначним ", це означає, що, крім того, у heads/masterвас є ще один майстер в одному з наступних просторів імен у репозиторії git:
refs/<refname>
refs/tags/<refname>
refs/heads/<refname>
refs/remotes/<refname>
refs/remotes/<refname>/HEAD
Або навіть ./<refname>, як уже згадувалося в Magnus «s відповідь .
./<refname>як згадував Магнус. (це було в моєму випадку)
Для подальшої довідки у мене була та сама проблема, і що в підсумку мені вдалось, це рішення, описане тут . В основному, коли ви отримуєте Git: warning: refname 'xxx' is ambiguousпопередження, ви можете використовувати: git show-ref xxxперевірити посилання на xxxгілку та перевірити, які з них мають конфлікт.
У моєму сценарії це був тег з іменем xxxта ім’ям гілки з однаковим ім’ям. Тег був зроблений помилково і був видалений з сервера , так що все що мені потрібно зробити , це обновити свій локальний тег , щоб відповідати сервера: git fetch -p -P. Ця команда детально пояснюється тут
git fetch --prune
git pull origin branch-name
має вирішити вашу проблему.
У мене була подібна проблема (не головна), коли я створив гілку з тим самим іменем, що і тег.
Це допомогло мені видалити тег https://stackoverflow.com/a/5480292/150953
git push --delete origin tagname