TL; DR
Возможно, вы хотите установить восходящий поток вашей ветви. Есть много способов сделать это, но самый прямой, на этом этапе, это использовать:
git branch --set-upstream-to=origin/new-branch new-branch
, после чего все используемые вами ярлыки будут работать.
Длинный: что это за ярлык
Чтобы по-настоящему понять это, вам нужно знать:
- что такое и действительно существует имя ветки Git (что не так много, но то, что оно имеет большое значение для людей);
- что такое имя для удаленного слежения ;
- что такое вверх по течению ветви есть; и
- как работает
git pull.
Имена ветвей и имена для удаленного слежения
Во-первых, что касается ветвей, здесь следует иметь в виду несколько вещей:
Git на самом деле совсем не о ветвях . Это действительно около коммитов . Коммиты на самом деле не названы по отраслям. Они действительно названы по номеру ha sh. Каждый Git повсюду соглашается, что любой конкретный коммит имеет этот га sh ID, и никакой другой коммит никогда не сможет использовать этот ха sh ID. Но идентификаторы ha sh выглядят случайными и их невозможно запомнить людям, поэтому ...
Имена ветвей в основном служат для find commits. Это означает, что мы, люди, очень сильно зависим от имен. Каждое название филиала содержит ровно один га sh ID . По определению, этот идентификатор ha sh является идентификатором ha sh для последнего коммита в ветви.
Ваш собственный Git имеет свои имена ветвей, которые не зависят от чьих-либо имен ветвей. Но поскольку эти имена полезны для нас, ваш Git также создаст имена для удаленного слежения , например origin/master, чтобы запомнить, что ваш Git видел в других Git (более поздних * 1064). *), в их master. Ваш Git будет обновлять эти имена для удаленного отслеживания всякий раз, когда ваш Git получает шанс.
Например, рассмотрите возможность запуска git fetch origin. Это заставляет Git вызывать их Git, используя короткое имя origin для поиска URL (их "номер телефона" Git). В их Git будут перечислены некоторые или все имена их ветвей, а также идентификаторы commit ha sh, которые go с этими именами. Ваш Git получит эти коммиты, если у вас их еще нет, и любые другие коммиты, которые go будут с этими коммитами, если у вас их еще нет. Так что теперь у вас есть все их коммиты - или все те, которые вам нужны для указанных c ответвлений, которые вы выбираете, если вы ограничили свои git fetch - и свой Git знает, какой коммит идентифицирует их ветвь Git. Следовательно, ваш Git теперь обновляет ваши имена для удаленного слежения - ваш origin/master и т. Д., Чтобы вы могли помнить их коммиты.
Помните, что каждый коммит, названный его уникальным идентификатором ha sh, также , внутри которого некоторые идентификаторы ha sh. Большинство коммитов содержат один га sh ID: это коммит этого parent коммита. Эти родительские идентификаторы формируют коммиты в обратных цепочках. Вот почему можно просто запомнить последний га sh ID. При заданном имени ветви, например master, Git находит последний коммит в цепочке, т. Е. tip ветви. Этот коммит запоминает следующий ранее коммит. При следующем более раннем коммите вспоминается еще более ранний коммит - прародитель типового коммита, а дедушка вспоминает еще более ранний коммит и т. Д.
git pull
Все git pull делает для вас две Git команды:
Сначала выполняется git fetch. Это то, что на самом деле получает новые коммиты. Шаг выборки также обновит ваши имена для удаленного отслеживания в зависимости от ситуации.
Новые зафиксированные вами коммиты, если таковые имеются, не повлияли на любые имен вашей ветви в все .
Затем запускается вторая команда Git. Эта вторая команда будет, или, по крайней мере, может повлиять на имя какой-либо ветви.
На какую ветку влияет эта вторая команда? Теоретически это может зависеть от второй команды. Какую вторую команду запускает git pull? Это под вашим контролем.
Вы можете выбрать git pull run git rebase. Если вы этого не сделаете, git pull запустит git merge. (Существуют редкие исключения, когда git pull использует еще одну опцию, но вы не включите их, если не создадите новый репозиторий с нуля.)
Прежде чем вы увидите, что git fetch выбирает, вы должен заранее решить, должны ли новые коммиты быть объединены с git merge или переназначены на с git rebase. Каким-то волшебным образом вы принимаете это решение, а затем запускаете git pull --rebase или просто git pull, а Git запускает две команды.
Команда second влияет на вашу текущая ветвь , потому что и перебазирование, и слияние влияют на текущую ветвь Это верно независимо от того, какие параметры и аргументы вы предоставляете git pull.
Так что ваша текущая ветвь имеет значение. И каждая ветвь в Git может иметь одну настройку upstream . Если вы запустите:
git pull origin new-branch
, то git pull игнорирует настройку восходящего потока (если есть). Имя origin указывает, куда fetch, а имя new-branch указывает, как запустить git merge или git rebase позже, после завершения выборки.
Но если вы запустите:
git pull
без дополнительных аргументов, git pull использует настройку восходящего потока. Это приводит нас к ...
Что такое восходящий поток и что он делает
Каждое имя ветви может иметь только один параметр восходящего потока. Или вы можете сбросить восходящий поток и, следовательно, не иметь восходящего потока. Если вы отключили восходящий поток - или у вас есть ветвь, в которой он никогда не был установлен - запуск git pull без аргументов просто на вас жаловался. Итак, одна вещь, устанавливающая восходящий поток, позволяет вам запускать git pull без аргументов.
Восходящий поток ветви - это просто другое имя. Обычно , это имя для удаленного слежения , как origin/master или origin/new-branch. Это состоит из двух частей: часть origin, которую git pull даст git fetch, и название ветви, как видно из другой Git. Их master становится вашим origin/master, поэтому имя удаленного слежения origin/master означает, по сути, их мастер .
Вы можете установить восходящую ветвь на ветвь в своем собственном Git. (Git сохраняет это внутренне, устанавливая «remote» на ., но git branch --set-upstream-to не нуждается в .: вы просто делаете git branch --set-upstream-to=develop feature, и теперь восходящий поток feature равен develop .) Для этого есть несколько небольших применений, но по большей части исходящие настройки должны ссылаться на некоторые другие Git.
Помимо настройки, чтобы вы могли запускать git pull без аргументов, а также разделите это на git fetch && git merge или git fetch && git rebase, также без лишних аргументов, если вы хотите разделить git pull, как я часто это делаю - вышестоящий поток позволяет вам:
- позволяет увидеть, как далеко впереди и / или позади вас, когда вы бежите
git status; и - влияет на
git push, в зависимости от значения push.default.
Некоторые команды создания ветви автоматически устанавливают восходящий поток для новой ветви, а некоторые - нет. Для получения дополнительной информации и ссылок и т. Д. См. Почему мне нужно "git pu sh --set-upstream origin "? и Зачем мне это делать? `--set-upstream` все время? .