Perché devo spingere esplicitamente un nuovo ramo?

Sono nuovo nel git e sto praticando. Ho creato una filiale locale ma ho visto che quando ho fatto git push mio ramo non è stato caricato nel repository. Dovevo davvero fare: git push -u origin --all .
Perchè è questo? Non è un ramo un nuovo cambiamento da spingere di default? Perché devo eseguire il secondo comando?

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

Quindi, quando si preme per la prima volta su un repository upstream vuoto (generalmente uno scoperto ), il repository upstream non ha alcuna filiale con lo stesso nome.

E:

  • la politica push predefinita era ” matching ” (spingere tutti i rami con lo stesso nome, creandoli se non esistono),
  • la politica push di default è ora ‘ simple ‘ (spinga solo il ramo corrente, e solo se ha un ramo di localizzazione remota chiamato allo stesso modo in upstream, dal git 1.7.11 )

In entrambi i casi, poiché il repository vuoto upstream non ha branch:

  • non c’è ancora un ramo con nome corrispondente
  • non esiste alcun ramo a monte (con o senza lo stesso nome! Tracciabilità o meno)

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

  • dove spingere
  • cosa spingere (poiché non riesce a trovare alcun ramo upstream che sia registrato come ramo di monitoraggio remoto e / o che abbia lo stesso nome)

Quindi è necessario almeno fare un:

 git push origin master 

Ma se fai solo questo, tu:

  • creerà un ramo master a monte sull’upstream (ora repo non vuoto): buono.
  • non registrerà che il ” master ” del ramo locale deve essere trasferito al ” master ” upstream ( origin ) (ramo upstream): bad.

Questo è il motivo per cui è consigliabile, per la prima spinta, fare un:

 git push -u origin master 

Questo registrerà l’ origin/master come un ramo di localizzazione remota , e consentirà alla spinta successiva di spingere automaticamente il master in origin/master .

 git checkout master git push 

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

Non lo fai, vedi sotto

Trovo questa ‘caratteristica’ piuttosto fastidiosa dal momento che non sto provando a lanciare razzi sulla luna, ma spingo il mio dannato ramo. Probabilmente lo fai anche tu altrimenti non saresti qui!

Ecco la soluzione: se si desidera che implicitamente spinga per il ramo corrente indipendentemente dal fatto che quel ramo esista sull’origine basta emettere questo comando una volta e non si dovrà mai più andare da nessuna parte:

 git config --global push.default current 

Quindi se fai rami come questo:

 git checkout -b my-new-branch 

e poi fare qualche commit e poi fare a

 git push -u 

per farli uscire all’origine (essendo su quel ramo) e creerà detto ramo per te se non esiste.

Si noti che -u bit si assicura che siano collegati se si dovesse prelevare successivamente da detto ramo. Se non hai in programma di tirare il ramo più tardi (o se stai bene con un altro rivestimento se lo fai) -u non è necessario.

Uscita di git push quando 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 push presuppone che esista già un ramo remoto che il ramo locale corrente sta monitorando. Se non esiste alcun ramo remoto di questo tipo e si desidera crearlo, è necessario specificarlo utilizzando il flag -u (forma abbreviata di --set-upstream ).

Perché è così? Immagino che gli implementatori abbiano pensato che creare un ramo sul telecomando sia un’azione così importante che dovrebbe essere difficile farlo per errore. git push è qualcosa che fai sempre.

“Non è un ramo un nuovo cambiamento da spingere di default?” Direi che “un cambiamento” in Git è un impegno. Un ramo è un puntatore a un commit. Per me ha più senso pensare a una spinta come qualcosa che spinge il commit verso gli altri repository. I commit sono determinati dal ramo in cui ci si trova e dalla relazione di tracciamento di quel ramo ai rami sul telecomando.

Puoi leggere ulteriori informazioni sul tracciamento dei rami nel capitolo Branche remote del libro Pro Git .

Non sono riuscito a trovare una spiegazione razionale dagli sviluppatori originali in questo modo, ma posso darti un’ipotesi basata su alcuni anni di esperienza Git.

No, non ogni ramo è qualcosa che vuoi spingere al mondo esterno. Potrebbe rappresentare un esperimento privato.

Inoltre, dove dovrebbe git push inviare tutti i rami? Git può funzionare con più telecomandi e potresti voler avere diversi gruppi di rami su ciascuno. Ad esempio, un repo GitHub del progetto centrale potrebbe avere rami di rilascio; una fork GitHub può avere filiali di argomenti da revisionare; e un server Git locale potrebbe avere filiali contenenti configurazione locale. Se git push spingesse tutti i rami verso il remoto che il ramo attuale tiene traccia, questo tipo di schema sarebbe facile da rovinare.

HEAD è l’abbreviazione per il ramo attuale quindi git push -u origine HEAD funziona. Ora per evitare questo digitando ogni volta che uso alias:

git config – global alias.pp ‘push -u origine HEAD’

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

git pp

Spero che questo faccia risparmiare tempo a qualcuno!

Al primo controllo

Step-1: git remote -v
// se viene trovato git initialize, rimuovere o saltare il passaggio 2

Step-2: git remote rm origin
// Quindi configura il tuo indirizzo email globalmente git

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

Step-4: git initial

Step-5: git commit -m "Initial Project"
// Se già aggiungi un repository di progetto, salta il passaggio 6

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

Step-7: git push -u origin master