Por que preciso enviar explicitamente uma nova ramificação?

Eu sou novo em git e estou praticando. Criei uma ramificação local, mas vi que, quando o fiz, git pushminha ramificação não foi carregada no repositório. Eu tinha que realmente fazer: git push -u origin --all.
Por que é isso? Uma ramificação não é uma nova alteração a ser enviada por padrão? Por que preciso executar o segundo comando?

O motivo real é que, em um novo repositório (git init), não há ramificação (não master, nenhuma ramificação, zero ramificação)

Então, quando você está empurrando pela primeira vez a um vazio repo a montante (geralmente um um nu ), que repo montante tem nenhum ramo de mesmo nome.

E:

• a política de envio padrão era ' matching' (envie todos os ramos com o mesmo nome, criando-os se eles não existirem),
• a política de envio padrão agora é ' simple' (envie apenas o ramo atual e somente se ele tiver um ramo de rastreamento remoto com nome semelhante no upstream, desde o git 1.7.11 )

Nos dois casos, como o repositório vazio a montante não tem ramificação:

• ainda não existe um ramo nomeado correspondente
• não há ramo upstream (com ou sem o mesmo nome! Rastreando ou não)

Isso significa que seu primeiro impulso local não tem idéia:

• onde empurrar
• o que enviar (já que não é possível encontrar nenhuma filial a montante registrada como filial de rastreamento remoto e / ou com o mesmo nome)

Então você precisa pelo menos fazer um:

git push origin master

Mas se você fizer apenas isso, você:

• criará um masterramo upstream no upstream (agora repositório não vazio): good.
• não registrará que a ramificação local ' master' precisa ser enviada para upstream ( origin) ' master' (ramificação upstream): incorreta.

É por isso que é recomendado, para o primeiro envio, fazer um:

git push -u origin master

Isso será gravado origin/mastercomo um ramo de rastreamento remoto e permitirá que o próximo envio seja enviado automaticamente masterpara origin/master.

git checkout master
git push

E isso também funcionará com políticas push ' current' ou ' upstream'.
Em cada caso, após o inicial git push -u origin master, um simples empurrão git será suficiente para continuar empurrando o mestre para o ramo direito a montante.

Você não vê, abaixo

Acho esse 'recurso' bastante irritante, já que não estou tentando lançar foguetes para a lua, apenas empurre meu maldito ramo. Você provavelmente também, ou não estaria aqui!

Aqui está a correção: se você deseja enviar implicitamente para o ramo atual, independentemente de esse ramo existir na origem, emita este comando apenas uma vez e você nunca precisará novamente em nenhum lugar:

git config --global push.default current

Então, se você criar galhos assim:

git checkout -b my-new-branch

e então faça alguns commit e então faça um

git push -u

para tirá-los da origem (estando nesse ramo) e criará o referido ramo para você, se não existir.

Observe que o bit -u garante que eles estejam vinculados se você puxar posteriormente do referido ramo. Se você não planeja puxar a ramificação mais tarde (ou está de acordo com outra linha, se o fizer) -u não é necessário.

Saída de git pushao empurrar uma nova ramificação

> 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

Um simples git push assume que já existe uma filial remota que a filial local atual está rastreando. Se não existir uma ramificação remota e você desejar criá-la, deverá especificar isso usando o sinalizador -u(formato abreviado de --set-upstream).

Por que é assim? Eu acho que os implementadores acharam que criar uma ramificação no controle remoto é uma ação tão importante que deve ser difícil fazê-lo por engano. git pushé algo que você faz o tempo todo.

"Uma ramificação não é uma nova alteração a ser enviada por padrão?" Eu diria que "uma mudança" no Git é um commit. Uma ramificação é um ponteiro para uma confirmação. Para mim, faz mais sentido pensar em um push como algo que empurra os outros repositórios. Quais confirmações são enviadas por push são determinadas por qual filial você está e o relacionamento de rastreamento dessa ramificação para ramificações no controle remoto.

Você pode ler mais sobre o rastreamento de ramificações no capítulo Ramificações remotas do livro Pro Git .

Não consegui encontrar uma justificativa dos desenvolvedores originais tão rapidamente, mas posso dar um palpite com base em alguns anos de experiência no Git.

Não, nem todo ramo é algo que você deseja enviar para o mundo exterior. Pode representar um experimento particular.

Além disso, para onde git pushenviar todas as filiais? O Git pode funcionar com vários controles remotos e você pode querer ter diferentes conjuntos de ramificações em cada um. Por exemplo, um repositório central do projeto GitHub pode ter ramificações de lançamento; um fork do GitHub pode ter ramificações de tópicos para revisão; e um servidor Git local pode ter ramificações contendo configuração local. Se git pushempurrar todas as ramificações para o controle remoto que a ramificação atual rastreia, seria fácil estragar esse tipo de esquema.

HEAD é a abreviação do ramo atual, portanto o git push -u origin HEAD funciona. Agora, para evitar essa digitação toda vez que eu usar o alias:

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

Depois disso, toda vez que eu quiser enviar por ramificação criada via git -b branch, posso enviá-la usando:

git pp

Espero que isso economize tempo para alguém!

Na primeira verificação

Etapa 1: git remote -v
// se o git encontrado for inicializado, remova ou pule a etapa 2

Etapa 2: git remote rm origin
// Em seguida, configure seu endereço de email globalmente git

Etapa 3: git config --global user.email "youremail@example.com"

Passo 4: git initial

Etapa 5: git commit -m "Initial Project"
// Se já adicionar repositório de projeto, pule a etapa 6

Etapa 6: git remote add origin %repo link from bitbucket.org%

Etapa 7: git push -u origin master

Acabei de experimentar uma permutação adicional desse problema.

Eu tinha um ramo chamado feat/XYZ-1234-some-descriptionporque estava trabalhando na edição 1234 do Jira. Durante o trabalho, criei um novo problema no Jira para rastrear um trabalho menor e, quando cheguei ao push, decidi usar o nome do ramo com esse novo número de problema. no:

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

Isso me deu o erro que está sendo discutido neste segmento SO. Mas como eu estava tentando passar para um nome de filial diferente da minha filial atual, meu problema era diferente do descrito aqui. Acabei renomeando minha filial local antes de poder enviá-la:

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

Depois de ler um pouco mais, percebi que poderia ter definido um srcno git pushnome do ramo atual ou apenas HEADse apropriado:

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

Se você habilitar o envio de novas alterações de sua nova filial pela primeira vez. E ficando abaixo do erro:

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

Para enviar a ramificação atual e definir o controle remoto como upstream, use

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'.