Текущая ветвь не отслеживает удаленную ветвь visual studio
Я учусь использовать Git с Visual Studio. Я недавно сделал запрос, где ветка была удалена после слияния. Ветвь функций по-прежнему отображается в моих локальных и удаленных ветвях в Visual Studio. Я знаю, как щелкнуть правой кнопкой мыши и удалить ветку, это обходной путь, поскольку другие в команде могут выполнить запрос на вытягивание в ветке, которую я имею, не зная об этом. Если они удалят ветку после этого, я не буду знать, что они это сделали так.
вопрос
Как обновить ветви Visual Studio с помощью того, что находится на Git?
чего я ожидал
Я ожидал бы, что кнопка, ссылка или функция щелчка правой кнопкой мыши, которая при щелчке проверяет наличие различий, если они найдены, спросит: "эта ветвь больше не существует, вы хотите удалить ее из Visual Studio?".
Технические Характеристики
Я использую Visual Studio 2015 Enterprise
дополнительные Пример
это может быть другой вопрос, но он подходит так хорошо здесь. Я просто заметил, что если я создаю ветку (скажем, в одной виртуальной машине и смотрю на то же РЕПО с другим), Visual Studio не имеет git fetch возможность обновления списка филиалов. Кнопка обновления вверху, похоже, ничего не делает. Как только я побегу git fetch в bash visual studio имеет новую ветвь. Я ожидал, что обновление позаботится об этом.
если ветвь была удалена на стороне сервера, попробуйте в командной строке (поскольку такая "кнопка", похоже, не существует непосредственно в Visual Studio):
(удалить --dry-run возможность фактически удалить локальные ветви)
удалите также соответствующую локальную ветвь git branch -d aBranch .
затем перезапустите Visual Studio , и проверьте, что он поднимает обновленный список ветвей. (комментарии упоминают, что вам не нужно перезапускать / обновлять VS)
это автоматизирует этот процесс и, кажется,поддерживается Visual Studio, as указанных ниже by Янив.
это удалит удаленные ветви из вашего списка при выполнении выборки.
вы можете настроить git, чтобы сделать это автоматически при выполнении fetch/pull с помощью этой команды:
обновление:
Visual Studio 2017 версии 15.7.3 и выше вы можете сделать это с помощью пользовательского интерфейса:
в Team Explorer нажмите кнопку Home, затем Установочный:
выберите Глобальные параметры
VS 2017, похоже, имеет поддержку, настраиваемую в Team Explorer:
Team Explorer Home Настройки Git > Глобальные Настройки Обрезать удаленные ветви во время выборки: Unset, True или False
вы должны отключить филиала во-первых, тогда другие заметят, что ветвь неопубликована(пытаясь вытащить ветвь, они получат ошибку), удаление локальной ветви на самом деле является отдельным процессом и должно быть сделано, чтобы избавиться от ветви в любом случае.
Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote <remote> или команды git remote show <remote> для получения удалённых веток и дополнительной информации. Тем не менее, более распространенным способом является использование веток слежения.
Ветки слежения — это ссылки на определённое состояние удалённых веток. Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удаленным репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
Имена веток слежения имеют вид <remote>/<branch> . Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master . Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53 , при том что у вас может быть своя локальная ветка iss53 , удалённая ветка будет представлена веткой слежения с именем origin/iss53 .
Подобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone . Если вы выполните git clone -o booyah , то по умолчанию ветка слежения будет иметь вид booyah/master .
Теперь вы можете выполнить команду git fetch teamone для получения всех изменений с сервера teamone , которых у вас нет локально. Так как в данный момент на этом сервере есть только те данные, что содержит сервер origin , Git ничего не получит, но создаст ветку слежения с именем teamone/master , которая будет указывать на тот же коммит, что и ветка master на сервере teamone .
Отправка изменений
Это в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix , что означает «возьми мою локальную ветку serverfix и обнови ей удалённую ветку serverfix ». Мы подробно рассмотрим часть с refs/heads/ в главе Git изнутри, но обычно её можно пропустить. Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится «возьми мою ветку serverfix и сделай её удалённой веткой serverfix ». Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы на удалённом сервере ветка называлась serverfix , то вместо предыдущей команды выполните git push origin serverfix:awesomebranch , которая отправит локальную ветку serverfix в ветку awesomebranch удалённого репозитория.
Если вы не хотите вводить свои данные каждый раз при отправке изменений, вы можете настроить «credential cache». Проще всего держать их в памяти несколько минут, это легко настроить с помощью команды git config --global credential.helper cache .
Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.
В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :
Необходимо отметить, что при получении данных создаются ветки слежения, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку serverfix — только указатель origin/serverfix , который вы не можете изменять.
Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна локальная ветка serverfix , в которой вы сможете работать, то вы можете создать её на основе ветки слежения:
Это даст вам локальную ветку, в которой можно работать и которая будет начинаться там же, где и origin/serverfix .
Отслеживание веток
Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется «upstream branch»). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull , то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния.
При клонировании репозитория, как правило, автоматически создаётся ветка master , которая следит за origin/master . Однако, при желании вы можете настроить отслеживание и других веток — следить за ветками на других серверах или отключить слежение за веткой master . Вы только что видели простейший пример, что сделать это можно с помощью команды git checkout -b <branch> <remote>/<branch> . Это часто используемая команда, поэтому Git предоставляет сокращённую форму записи в виде флага --track :
В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:
Чтобы создать локальную ветку с именем, отличным от имени удалённой ветки, просто укажите другое имя:
Теперь ваша локальная ветка sf будет автоматически получать изменения из origin/serverfix .
Если у вас уже есть локальная ветка и вы хотите настроить ее на слежение за удалённой веткой, которую вы только что получили, или хотите изменить используемую upstream-ветку, то воспользуйтесь параметрами -u или --set-upstream-to для команды git branch , чтобы явно установить новое значение.
Если у вас настроена отслеживаемая ветка, вы можете ссылаться на нее с помощью сокращений @ или @ . Итак, если вы находитесь на ветке master и она следит за origin/master , при желании вы можете использовать git merge @ вместо git merge origin/master .
Если вы хотите посмотреть как у вас настроены ветки слежения, воспользуйтесь опцией -vv для команды git branch . Это выведет список локальных веток и дополнительную информацию о том, какая из веток отслеживается, отстаёт, опережает или всё сразу относительно отслеживаемой.
Итак, здесь мы видим, что наша ветка iss53 следит за origin/iss53 и «опережает» её на два изменения — это значит, что у нас есть два локальных коммита, которые не отправлены на сервер. Мы также видим, что наша ветка master отслеживает ветку origin/master и находится в актуальном состоянии. Далее мы можем видеть, что локальная ветка serverfix следит за веткой server-fix-good на сервере teamone , опережает её на три коммита и отстает на один — это значит, что на сервере есть один коммит, который мы ещё не слили, и три локальных коммита, которые ещё не отправлены на сервер. В конце мы видим, что наша ветка testing не отслеживает удаленную ветку.
Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, вам необходимо получить данные со всех ваших удалённых серверов перед запуском команды. Сделать это можно вот так:
Получение изменений
Команда git fetch получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей копии. Эта команда просто получает данные и позволяет вам самостоятельно сделать слияние. Тем не менее, существует команда git pull , которая в большинстве случаев является командой git fetch , за которой непосредственно следует команда git merge . Если у вас настроена ветка слежения как показано в предыдущем разделе, или она явно установлена, или она была создана автоматически командами clone или checkout , git pull определит сервер и ветку, за которыми следит ваша текущая ветка, получит данные с этого сервера и затем попытается слить удалённую ветку.
Обычно, лучше явно использовать команды fetch и merge , поскольку магия git pull может часто сбивать с толку.
Удаление веток на удалённом сервере
Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя параметр --delete для команды git push . Для удаления ветки serverfix на сервере, выполните следующую команду:
Всё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.
Я только что настроил Visual Studio 2015 с подключением к GitHub. К сожалению, это не работает для отслеживания удаленной ветви. У меня 2 проекта в одном решении, у каждого свой репозиторий. Для каждого из них - у меня только одна ветвь (Master) - я проверил, что удаленная ветвь была установлена правильно (Push и fetch имеют одинаковое значение). Я в итоге сбрасываю ветки - В Синхронизации только "Fetch" не выделяется серым цветом. Нажатие на него не синхронизируется. Под "Incoming Commit" написано "Текущая ветка не отслеживает удаленную ветку". - При работе с Git GUI все работает нормально, я могу легко получить и нажать.
Пожалуйста, спросите, если вам нужна дополнительная информация.
1 ответ
Пользовательский интерфейс не очень ясно дает понять, что вы должны использовать Publish без добавления удаленного репо.
Если вы сначала добавляете удаленный, Publish никогда не становится доступным, и вы застреваете в состоянии "не отслеживает удаленную ветвь". У меня только что была такая же проблема в VS2017.
Неправильный путь:
Вы можете подумать, что прежде чем вы сможете синхронизироваться с удаленным, вы должны рассказать Visual Studio об удаленном. Не делай этого.
Вместо этого нажмите Sync:
Visual Studio обнаруживает, что для репо не настроен пульт, и открывает диалоговое окно Push:
Нажмите соответствующую кнопку публикации, и появится окно ввода. Это правильное место для настройки Visual Studio с URL-адресом удаленного хранилища.
Когда пульт добавляется таким образом, Visual Studio распознает состояние удаленного репо, так что он больше не думает, что он не отслежен. Отныне он включает все функции синхронизации /push, как и ожидалось.
Я работаю над проектом C ++ с несколькими другими людьми в Visual Studio Community 2015, и мы хотели бы использовать встроенные функции git VS2015 для управления нашим проектом. Мы хотели бы, чтобы каждый пользователь имел локальный репозиторий git на своем ноутбуке, а затем поместил удаленный репозиторий на сетевой диск, который мы отправляем / извлекаем. Я хотел бы знать правильный рабочий процесс для этой конкретной установки, используя встроенные функции git VS2015. Мы НЕ хотим использовать VS online или Team Foundation Version version или версию git для командной строки (из-за характера нашей работы у нас не будет доступа к Интернету, и у нас нет доступа к командной строке).
Я попробовал несколько вещей, чтобы заставить это работать без всякой удачи.
Сначала я открываю решение в VS2015, затем нажимаю файл -> добавить в систему управления версиями -> git, который создает локальный репозиторий. Затем я фиксирую свои файлы в локальном хранилище. Пока проблем нет.
Поэтому, чтобы попытаться создать пустое git-репо, я перехожу в File-> new-> Repository и создаю git-репозиторий в папке на сетевом диске. Я думаю, введите это в Синхронизация -> URL, и я получаю другую ошибку. Эта ошибка говорит о том, что локальное push-уведомление еще не поддерживает размещение в репозиториях, не являющихся открытыми. Создание нового репозитория в VS2015, похоже, не создает пустой репозиторий.
Затем я попытался клонировать расположение моего локального репозитория в расположение папки сетевого диска, что сработало. Затем я захожу в настройки локального репозитория и добавляю удаленный репозиторий к удаленным, который теперь отображается в окнах проводника ветвей. Затем я изменяю свой код, перехожу к изменениям и выбираю Commit и Push. На этот раз я получаю еще одну ошибку: «Невозможно нажать, потому что текущая ветвь не отслеживает удаленную ветвь, публикует изменения на удаленной». Когда я щелкаю правой кнопкой мыши по локальной ветке master, опция публикации становится недоступной, поэтому я не могу ее опубликовать.
Чтобы обойти эту проблему, я щелкаю правой кнопкой мыши по удаленной / основной ветке и выбираю новую локальную ветку с выбранной опцией «Отслеживать удаленную ветвь (настроить для push и pull с удаленной / главной)». Я называю эту ветку local_master, которая сейчас является опубликованной веткой. Я предположил, что опция, которую я выбрал выше, позволит мне теперь перенести и перенести изменения из моей новой опубликованной ветви local_master в удаленную / главную ветку. Когда я делаю изменения в local_master, фиксирую, а затем пытаюсь нажать, я вместо этого получаю эту ошибку: «Локальное нажатие (пока) не поддерживает передачу в не-голые репо». Затем я щелкаю правой кнопкой мыши на ветке remote / master и пытаюсь слиться с моим local_master в remote / master, который говорит, что он работал успешно, но мои изменения кода отсутствуют в remote / master.
Я потратил почти 8 часов, пытаясь заставить это работать и исследуя другие решения, и не добился успеха, и я почти сошел с ума. Кто-нибудь знает, как создать удаленный репозиторий на сетевом диске, а затем перенести / вытащить из локального репозитория в удаленный репозиторий, используя встроенные элементы управления git в VS2015?
Решение
Это мой текущий рабочий процесс:
Очевидно, что многие из этих шагов могут быть выполнены немного по-другому или не в порядке, но важная концепция состоит в том, чтобы инициализировать пустой репозиторий на сетевом ресурсе, а затем локально клонировать его в качестве полного репозитория.
Причина, по которой вы удаляете существующий репо и клон с общего сетевого ресурса, заключается в том, чтобы убедиться, что все ваши пульты настроены правильно.
Читайте также: