Зачем мне явно выдвигать новую ветку?

Question

Я новичок в git и я тренируюсь Я создал местный филиал, но увидел, что когда git push моя ветка не была загружена в хранилище. Я должен был сделать: git push -u origin --all,
Почему это? Разве ветвь не является новым изменением, которое будет добавлено по умолчанию? Почему мне нужно запустить вторую команду?

Answer 1

Фактическая причина в том, что в новом репо (git init) нет ветки (нет master ветки нет, ветки ноль)

Поэтому, когда вы в первый раз продвигаетесь к пустому репозиторию в восходящем направлении (как правило, в пустое), в этом репозитории в обратном потоке нет ветви с тем же именем.

А также:

• политика push по умолчанию была matching ' (нажмите на все ветви с одинаковым именем, создавая их, если они не существуют),
• политика push по умолчанию сейчас simple' (выдвигать только текущую ветвь, и только если она имеет аналогично названную ветвь удаленного отслеживания в восходящем потоке, начиная с git 1.7.11)

В обоих случаях, поскольку обратное пустое хранилище не имеет ветки:

• пока нет соответствующей именованной ветви
• нет восходящей ветки вообще (с тем же именем или без него! Отслеживание или нет)

Это означает, что ваш местный первый толчок понятия не имеет:

• куда толкать
• что нажать (так как он не может найти какую-либо ветку восходящего потока, либо записанную как удаленную ветвь отслеживания, и / или имеющую то же имя)

Так что вам нужно хотя бы сделать:

git push origin master

Но если вы делаете только это, вы:

• создаст вверх по течению master ветка в апстриме (сейчас непустое репо): хорошо.
• не будет записывать, что местное отделение master нужно подтолкнуть вверх по течению (origin) ' master ' (ветка вверх по течению): плохо.

Вот почему рекомендуется для первого нажатия:

git push -u origin master

Это будет записывать origin/master как удаленная ветвь отслеживания, и включит следующее нажатие, чтобы автоматически нажать master в origin/master,

git checkout master
git push

И это тоже будет работать с политикой push current ' или же ' upstream ".
В каждом случае после первоначального git push -u origin master простого git push будет достаточно, чтобы продолжить толкать master в правую ветку upstream.

Answer 2

Вы не видите ниже

Я нахожу эту "особенность" довольно раздражающей, поскольку я не пытаюсь запускать ракеты на Луну, просто нажмите на мою чертову ветку. Вы, вероятно, тоже, иначе вы не были бы здесь!

Вот исправление: если вы хотите, чтобы он неявно выдвигал текущую ветвь независимо от того, существует ли эта ветвь в источнике, просто выполните эту команду один раз, и вам больше никогда не придется нигде:

git config --global push.default current

Так что, если вы делаете ветки так:

git checkout -b my-new-branch

а затем сделать некоторые коммиты, а затем сделать

git push -u

вывести их в исходное положение (находясь в этой ветке), и он создаст для вас указанную ветку, если она не существует.

Обратите внимание, что бит -u гарантирует, что они связаны, если позже вы извлечете их из указанной ветви. Если вы не планируете тянуть ветку позже (или у вас все в порядке с другим лайнером, если вы это делаете) -u не требуется.

Answer 3

Выход из git push при нажатии на новую ветку

> git checkout -b new_branch
Switched to a new branch 'new_branch'
> git push
fatal: The current branch new_branch has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new_branch

Просто git push Предполагается, что уже существует удаленная ветвь, которую отслеживает текущая локальная ветвь. Если такой удаленной ветви не существует, и вы хотите ее создать, вы должны указать это с помощью -u (краткая форма --set-upstream) флаг.

Почему это так? Я предполагаю, что разработчики чувствовали, что создание ветки на удаленном компьютере является настолько важным действием, что это должно быть трудно сделать по ошибке. git push это то, что вы делаете все время.

"Разве ветвь не является новым изменением, которое будет добавлено по умолчанию?" Я бы сказал, что "изменение" в Git - это коммит. Ветвь - это указатель на коммит. Для меня имеет больше смысла думать о push как о чем-то, что подталкивает коммиты в другие репозитории. То, какие коммиты отправляются, определяется тем, в какой ветке вы находитесь, и отношениями отслеживания этой ветви к удаленным веткам.

Подробнее о отслеживании веток вы можете прочитать в главе "Удаленные ветки" книги Pro Git.

Answer 4

Первоначальные разработчики не смогли найти разумного объяснения, но я могу дать вам обоснованное предположение, основанное на нескольких годах опыта работы с Git.

Нет, не каждая отрасль - это то, что вы хотите подтолкнуть к внешнему миру. Это может быть частный эксперимент.

Более того, где следует git push отправить все ветки? Git может работать с несколькими пультами, и вы можете захотеть иметь разные наборы веток на каждом. Например, центральный проект GitHub repo может иметь ветки релизов; у ветки GitHub могут быть ветки тем для обзора; и локальный сервер Git может иметь ветви, содержащие локальную конфигурацию. Если git push подтолкнет все ветви к пульту, который отслеживает текущая ветвь, такую ​​схему легко испортить.

Answer 5

HEAD - это сокращение от текущей ветви, поэтому git push -u origin HEAD работает. Теперь, чтобы избежать этой типизации каждый раз, когда я использую псевдоним:

git config --global alias.pp 'push -u origin HEAD'

После этого, каждый раз, когда я хочу отправить ветку, созданную через ветку git -b, я могу нажать ее, используя:

мерзавец пп

Надеюсь, это сэкономит время для кого-то!

Answer 6

При первой проверке

Шаг 1: git remote -v
// если найден git initialize, то удалить или пропустить шаг-2

Шаг 2: git remote rm origin
// Затем настройте ваш адрес электронной почты глобально git

Шаг 3: git config --global user.email "[e-mail]"

Шаг 4: git initial

Шаг 5: git commit -m "Initial Project"
// Если вы уже добавили репозиторий проекта, пропустите шаг 6

Шаг 6: git remote add origin %repo link from bitbucket.org%

Шаг 7: git push -u origin master

Answer 7

Я только что испытал дальнейшую перестановку этой проблемы.

У меня была ветка с названием feat/XYZ-1234-some-description потому что я работал над проблемой Jira 1234. Во время работы я создал новую задачу Jira, чтобы отслеживать меньшую часть работы, и когда я пришел к push, я решил нажать на имя ветки с этим новым номером проблемы в:

git push -u origin feat/XYZ-5678-a-different-description # failed

Это дало мне ошибку, обсуждаемую в этой ветке SO. Но поскольку я пытался перейти на другое имя ветки из моей текущей ветки, моя проблема отличалась от описанной здесь. В итоге я переименовал свою локальную ветку, прежде чем смог ее нажать:

git branch -m feat/XYZ-1234-some-description feat/XYZ-5678-a-different-description
git push -u origin feat/XYZ-5678-a-different-description # now works

После небольшого чтения я понял, что мог бы установить src на git push, либо к текущему имени ветки, либо просто HEAD если уместно:

git push -u origin feat/XYZ-1234-some-description:feat/XYZ-5678-a-different-description # also works

Answer 8

Если вы разрешили отправлять новые изменения из вашей новой ветки в первый раз. И ошибка ниже:

*git push -f
fatal: The current branch Coding_Preparation has no upstream branch.

Чтобы протолкнуть текущую ветвь и установить удаленный как восходящий поток, используйте

git push -u origin new_branch_name


** Successful Result:** 
 git push -u origin Coding_Preparation
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 599 bytes | 599.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'Coding_Preparation' on GitHub by visiting: ...
 * [new branch]      Coding_Preparation -> Coding_Preparation
Branch 'Coding_Preparation' set up to track remote branch 'Coding_Preparation' from 'origin'.