Perché devo spingere esplicitamente un nuovo ramo?

Sono nuovo gite mi sto esercitando. Ho creato un ramo locale ma ho visto che quando lo facevo il git pushmio ramo non veniva caricato nel repository. Ho dovuto fare in realtà: git push -u origin --all.
Perchè è questo? Una filiale non è una nuova modifica da inserire per impostazione predefinita? Perché devo eseguire il secondo comando?

Il vero motivo è che, in un nuovo repository (git init), non esiste un ramo (no master, nessun ramo, zero rami)

Così, quando si sta spingendo per la prima volta a un vuoto di pronti contro termine a monte (generalmente una spoglia uno ), che repo a monte non ha ramo con lo stesso nome.

E:

• la politica push predefinita era ' matching' (push tutte le filiali con lo stesso nome, creandole se non esistono),
• il criterio push predefinito ora è ' simple' (invia solo il ramo corrente e solo se ha un ramo di tracciamento remoto con nome simile su upstream, da git 1.7.11 )

In entrambi i casi, poiché il repository vuoto a monte non ha alcun ramo:

• non esiste ancora un ramo con nome corrispondente
• non esiste alcun ramo a monte (con o senza lo stesso nome! Tracciamento o meno)

Ciò significa che la tua prima spinta locale non ha idea:

• dove spingere
• cosa spingere (poiché non riesce a trovare alcun ramo a monte registrato o come ramo di tracciamento remoto e / o con lo stesso nome)

Quindi devi almeno fare un:

git push origin master

Ma se fai solo quello, tu:

• creerà un masterramo upstream sull'upstream (ora repository non vuoto): buono.
• non registra che il ramo locale ' master' deve essere trasferito a monte ( origin) ' master' (ramo a monte): cattivo.

Ecco perché si consiglia, per la prima volta, di fare un:

git push -u origin master

Ciò verrà registrato origin/mastercome un ramo di tracciamento remoto e consentirà alla spinta successiva di passare automaticamente mastera origin/master.

git checkout master
git push

E funzionerà anche con le politiche push ' current' o ' upstream'.
In ogni caso, dopo l'iniziale git push -u origin master, sarà sufficiente una semplice git push per continuare a spingere il master verso il ramo upstream destro.

No, vedi sotto

Trovo questa 'caratteristica' piuttosto fastidiosa poiché non sto provando a lanciare razzi sulla luna, spingo solo il mio dannato ramo. Probabilmente lo farai anche tu altrimenti non saresti qui!

Ecco la soluzione: se vuoi che spinga implicitamente per il ramo corrente indipendentemente dal fatto che quel ramo esista sull'origine, basta emettere questo comando una volta e non dovrai mai più dovunque:

git config --global push.default current

Quindi se fai rami come questo:

git checkout -b my-new-branch

e poi fai qualche commit e poi fai un

git push -u

per portarli all'origine (trovandosi su quel ramo) e creerà detto ramo per te se non esiste.

Si noti che il bit -u si assicura che siano collegati se si dovesse tirare in seguito da detto ramo. Se non hai intenzione di estrarre il ramo in seguito (o stai bene con un altro liner se lo fai) -u non è necessario.

Uscita di git pushquando si spinge un nuovo ramo

> 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

Un semplice git pushpresuppone che esista già un ramo remoto che il ramo locale corrente sta monitorando. Se non esiste tale ramo remoto e si desidera crearlo, è necessario specificarlo utilizzando il flag -u(forma breve di --set-upstream).

Perché è così? Immagino che gli implementatori abbiano ritenuto che la creazione di un ramo sul telecomando sia un'azione così importante che dovrebbe essere difficile farlo per errore. git pushè qualcosa che fai tutto il tempo.

"Un ramo non è una nuova modifica da inserire per impostazione predefinita?" Direi che "un cambiamento" in Git è un commit. Un ramo è un puntatore a un commit. Per me ha più senso pensare a una spinta come a qualcosa che spinge si impegna negli altri repository. Quali commit vengono spinti è determinato dal ramo in cui ci si trova e dalla relazione di tracciamento di quel ramo con i rami sul telecomando.

Puoi leggere ulteriori informazioni sul monitoraggio dei rami nel capitolo Rami remoti del libro Pro Git .

Non sono riuscito a trovare una logica degli sviluppatori originali così rapidamente, ma posso darti un'idea ipotetica basata su alcuni anni di esperienza con Git.

No, non tutti i rami sono qualcosa che vuoi spingere verso il mondo esterno. Potrebbe rappresentare un esperimento privato.

Inoltre, dove dovrebbero git pushinviare tutte le filiali? Git può funzionare con più telecomandi e potresti voler avere diversi set di rami su ciascuno. Ad esempio, un repository GitHub di progetto centrale può avere diramazioni di rilascio; un fork GitHub può avere rami di argomento per la revisione; e un server Git locale può avere filiali contenenti configurazione locale. Se git pushspingesse tutti i rami sul telecomando tracciati dal ramo corrente, questo tipo di schema sarebbe facile da rovinare.

HEAD è l'abbreviazione di ramo corrente, quindi git push -u origine HEAD funziona. Ora per evitare questa digitazione ogni volta che uso l'alias:

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

Dopo questo, ogni volta che voglio spingere il ramo creato tramite il ramo git -b posso spingerlo usando:

git pp

Spero che questo risparmi tempo per qualcuno!

Al primo controllo

Passaggio 1: git remote -v
// se trovato git inizializza, quindi rimuovere o saltare il passaggio 2

Step-2: git remote rm origin
// Quindi configura il tuo indirizzo email a livello globale git

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

Step-4: git initial

Passaggio 5: git commit -m "Initial Project"
// Se si aggiunge già un repository di progetti, saltare il passaggio 6

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

Step-7: git push -u origin master

Ho appena sperimentato un'ulteriore permutazione di questo problema.

Avevo un ramo chiamato feat/XYZ-1234-some-descriptionperché stavo lavorando al numero di Jira 1234. Durante il lavoro ho creato un nuovo numero di Jira per tenere traccia di un lavoro più piccolo, e quando sono arrivato a spingere ho deciso di passare a un nome di ramo con questo nuovo numero di rilascio nel:

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

Questo mi ha dato l'errore discusso in questo thread SO. Ma dal momento che stavo cercando di spingere su un nome di ramo diverso dal mio ramo attuale, il mio problema era diverso da quello descritto qui. Ho finito per rinominare la mia filiale locale prima di poterlo spingere:

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

Dopo un po 'più di lettura in giro mi sono reso conto che avrei potuto impostare un src su git push, sul nome del ramo corrente, o solo HEADse appropriato:

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

Se abiliti a inviare nuove modifiche dalla nuova filiale per la prima volta. E ottenere sotto l'errore:

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

Per spingere il ramo corrente e impostare il telecomando come a monte, usare

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