TL; DR
Возможно, вам просто нужно запустить git checkout branch (что, я думаю, вы уже сделали), а затем перезапустить Atom (убить его полностью; он имеет тенденцию продолжать работать, чтобы быстро запускаться)и открывать окна легко).На самом деле я не использовал Atom, так что это предположение - его плагин может предполагать, что только плагин делает что-то, связанное с Git, так что он никогда не пересканирует после того, как вы что-то сделаете в командной строке.
Aздесь может быть полезно подробное описание того, что на самом деле происходит.
Long
Я расскажу здесь о git fetch и системе имен Git.
notebaby-steps-demo больше не существует в проекте GitLab ...
Это достаточно нормально: по умолчанию git fetch не удаляет имена для удаленного отслеживания, этобудет только создавать или обновлять их.
Здесь есть несколько частей.У вас есть ваш Git-репозиторий, на сервере есть его Git-репозиторий, и каждый репозиторий имеет своих собственных имен ветвей.Но ваш репозиторий Git должен помнить имена других репозитория Git.Таким образом, ваш репозиторий Git имеет, в дополнение к вашим (локальным) именам ветвей, набор имен для удаленного отслеживания , которые соответствуют тому, что имел другой репозиторий Git - или имел, когда в последний раз ваш Git общался со своимиGit.
Это может помочь вашей визуализации того, что происходит, если вы запустите из командной строки:
git ls-remote origin
Это показывает, что первые несколько шагов git fetch origin (или git fetch, который идет к origin) делать:
- Вызывать другого Git по любому, что
git config --get remote.origin.url говорит. Получите от них список всех их ссылки (технический термин, охватывающий как ветви, так и теги; есть и другие, но ваш Git не будет заботиться ни о чем, кроме имен их веток и тегов) и соответствующие им значения хеш-идентификатора.
Для моего Git-репозитория для Git, когда я запускаю git ls-remote origin,, первые несколько строк:
3e5524907b43337e82a24afbc822078daf7a868f HEAD
fc54c1af3ec09bab8b8ea09768c2da4069b7f53e refs/heads/maint
3e5524907b43337e82a24afbc822078daf7a868f refs/heads/master
61856ae69a2ceb241a90e47953e18f218e4d5f2f refs/heads/next
, например.
Однажды ваш git fetchимеет эту информацию, она определяет, какие ветви он хочет перенести (ихmaint, master и т. Д. - их ветви), поэтому он проверяет, есть ли у вас коммиты fc54c1a..., 3e55249... и т. Д.
Что бы вас ни фиксировало не делайтеt , ваш Git запрашивает свой Git вместе с другими объектами, необходимыми для завершения вашего хранилища.Все это происходит в довольно быстром обмене «У меня есть Х, но мне нужен Y», после чего их Git создает файл пакета , чтобы отправить вам:
remote: counting objects ...
remote: compressing objects ...
Как только ониотправил вам все, ваш Git сжимает эти объекты, проиндексированные по их хэш-идентификаторам, в вашей базе данных.Если вы (или ваш Git, на самом деле) не выбросили их в какой-то момент, теперь, когда у вас есть эти объекты, вам больше не нужно извлекать их снова.
Наконец, вашему Git нужно установить какое-нибудь имя или имена , с помощью которых запомните эти объекты или, более конкретно, их хэш-идентификаторы.Если ваш Git не знает, почему у него есть эти объекты - если у него нет имени, по которому он может их найти - он в конечном итоге выбросит их.Единственное место, где хранятся хеш-идентификаторы - это специальный файл FETCH_HEAD.Каждая новая выборка перезаписывает этот файл всем, что получено, так что то, что вы получили, по крайней мере, остается до следующего git fetch.Но более важным для ваших целей здесь - потому что он длится гораздо дольше - является то, что ваш Git переименовывает их имена ветвей:
refs/heads/master становится refs/remotes/origin/masterrefs/heads/next становится refs/remotes/origin/next
Затем ваш Git создает или обновляет имя в правой части этого набора.Это ваши имена для удаленного слежения .
В целях отображения Git сокращает они, тем не менее, отбрасывают по крайней мере refs/ и обычно следующее слово, разделенное слешем, какЧто ж.Команда git fetch префиксирует все это с помощью сокращенных хеш-идентификаторов:
aaaaaaa..bbbbbbb master -> origin/master
, т. Е.Дадим вам, что ваш Git обновил ваш refs/remotes/origin/master на основе их refs/heads/master, и в то же время, что ваш refs/remotes/origin/master использовал name commit aaaaaaa и теперь имена вместо commit bbbbbbb.Или:
* [new branch] branch -> origin/branch
, который сообщает вам, что ваш Git создал ваш refs/remotes/origin/branch только сейчас, основываясь на просмотре refs/heads/branch в списке git ls-remote.
Обратите внимание, что ваше origin/baby-steps-demo - полное имя действительно refs/remotes/origin/baby-steps-demo;оно просто сокращено для отображения - это ваше имя удаленного отслеживания , а не имя ветви . 1 Имя ветви - это имя, полная версия которого начинается с refs/heads/.
Теперь мы можем вернуться к этому замечанию:
заметьте, что baby-steps-demo больше не существует в проекте GitLab ...
Это означает, что когда ваш Git вызывает свой Git, они не перечисляют refs/heads/baby-steps-demo.
Ваш Git использовал свои baby-steps-demo для создания вашего origin/baby-steps-demo.Должен ли ваш Git удалить ваш origin/baby-steps-demo?Если вы хотите, чтобы ваш Git использовался, вы можете указать своему Git использовать его полный список всех своих веток для prune ваших имен для удаленного слежения.Вы можете сделать это с помощью git fetch --prune или установить fetch.prune на true в вашей конфигурации Git, чтобы заставить git fetch делать это по умолчанию.
Команда командной строки git branch -r показывает только и толькоэти имена для удаленного отслеживания.
Команда командной строки git branch (без -r) показывает только и только ваши имена ветвей.Они не зависят от наличия имен для удаленного отслеживания (и наоборот).
Каждая (локальная) ветвь может иметь один, но только один, upstream .В восходящем потоке для ветки наподобие master, которую вы создаете на основе имени удаленного отслеживания, например origin/master, обычно имя удаленного отслеживания устанавливается в качестве восходящего, но это то, что вам может потребоваться указать Git для установки, в зависимости откак именно вы создали (локальное) имя ветки.
Некоторые операции, включая git pull, используют настройку восходящего потока для определения того, что git fetch, а что git merge после завершения git fetch.Если ваша ветвь не имеет установленного восходящего потока, они не могут или не будут принимать некоторые значения по умолчанию.
В вашем случае, ваша текущая ветвь branch не имеет origin/branch в качестве восходящего потока (какэто не имеет никакого восходящего набора вообще).Если вы запустите:
git branch --set-upstream-to=origin/branch branch
, вы скажете вашему Git установить origin/branch в качестве восходящего потока для вашей ветви с именем branch.Если бы до этого были какие-то другие настройки восходящего потока, это заменило бы старый параметр восходящего потока на новый.
Параметр восходящего потока - это просто пара имен;git branch --set-upstream-to проверяет, что имена существуют и являются действительными, а затем устанавливает их, а git branch --unset-upstream полностью их удаляет (так что у ветви больше нет восходящего потока, если вы хотите сделать это по любой причине).
1 Этот набор фраз явно оставляет желать лучшего.Если ветвь - это то, что вы можете «включить» с помощью git checkout, тогда имя удаленного отслеживания или имя удаленного отслеживания не является веткой, потому что git checkout origin/masterили что-то подобное оставляет вас в режиме detached HEAD .Более того, имя для удаленного отслеживания (ветви) - это то, что ваши собственные Git хранят локально!Но некоторым людям нравится думать об именах удаленного отслеживания как об именах ветвей, и у них есть поведение "branch-y".