Che cos'è "git remote add ..." e "git push origin master"?

288

Molto spesso, Git e Rails sembrano magici ... come nel primo capitolo del libro di tutorial di Rails 3 , parla di Git:

git remote add origin git@github.com:peter/first_app.git
git push origin master

e praticamente dice "funziona" senza dire troppo su quello che sono e iniziare a parlare di ramificazione. Cercando sul spettacoli rete che git remote addè quello di aggiungere un "nome breve", come ad esempio origin, e può essere qualsiasi nome pure, che è come un alias a un URL. Ed originè il solito percorso verso cui punta il repository remoto. (in http://git-scm.com/book/en/Git-Basics-Working-with-Remotes in "Aggiunta di repository remoti")

Quindi perché l'URL non è git://git@github.com/peter/first_app.gitma nell'altra sintassi: che sintassi è? Perché deve finire con .git? Ho provato a non usare .gitalla fine e funziona anche. In caso contrario .git, cos'altro può essere? L' gitin git@github.comsembra essere un account utente sul server git?

Inoltre, perché deve essere così prolisso da usare git push origin master? L'impostazione predefinita non può essere origine e master? Ho scoperto che la prima volta origin masterè necessario, ma dopo una piccola modifica e commit, git pushè tutto ciò di cui ha bisogno (non è necessario origin master). Qualcuno che sa cosa sta succedendo può fornire alcuni dettagli?

A volte sembra molta magia senza spiegazioni ... e a volte la persona che la usa è così sicura di sé e quando gli viene chiesto perché, non può spiegarlo e rispondere con qualcosa del tipo "così è". A volte molto pratico e pragmatico. Non è male essere pratici, ma probabilmente non pratici al punto da non sapere cosa sta succedendo.

git github

— nonopolarity
fonte

344

gitè come UNIX. Facile da usare ma esigente per i suoi amici. È potente e facile da usare come una pipeline di shell.

Detto questo, una volta compresi i paradigmi e i concetti, ha la stessa chiarezza zen che mi sono aspettato dagli strumenti della riga di comando di UNIX. Dovresti prendere in considerazione un po 'di tempo libero per leggere uno dei tanti buoni tutorial git disponibili online. Il libro Pro Git è un buon punto di partenza.

Per rispondere alla tua prima domanda.

Cosa è git remote add ...

Come probabilmente saprai, gitè un sistema di controllo versione distribuito. La maggior parte delle operazioni viene eseguita localmente. Per comunicare con il mondo esterno, gitusa ciò che viene chiamato remotes. Si tratta di repository diversi da quello sul disco locale in cui è possibile pushmodificare (in modo che altre persone possano vederli) o pullda (in modo da poter ottenere altre modifiche). Il comando git remote add origin git@github.com:peter/first_app.gitcrea un nuovo telecomando chiamato originsituato in git@github.com:peter/first_app.git. Una volta fatto questo, nei tuoi comandi push, puoi spingere origininvece di digitare l'intero URL.
Cosa è git push origin master

Questo è un comando che dice "invia i commit nel ramo locale chiamato masternel telecomando chiamato origin". Una volta eseguito questo, tutte le cose che hai sincronizzato l'ultima volta con origin verranno inviate al repository remoto e altre persone potranno vederle lì.

Ora sui trasporti (cioè cosa git://) significa. Gli URL del repository remoto possono essere di molti tipi ( file://, https://ecc.). Git si affida semplicemente al meccanismo di autenticazione fornito dal trasporto per occuparsi di autorizzazioni e cose. Ciò significa che per gli file://URL saranno permessi per i file UNIX, ecc. Lo git://schema sta chiedendo a git di usare il proprio protocollo di trasporto interno, che è ottimizzato per l'invio di changeset git. Per quanto riguarda l'URL esatto, è il modo in cui è a causa del modo in cui Github ha configurato il suo gitserver.

Ora la verbosità. Il comando che hai digitato è quello generale. È possibile dire a git qualcosa come "il ramo chiamato masterqui è il mirror locale del ramo chiamato foosul telecomando chiamato bar". In parole povere, questo significa che master tracce bar/foo . Quando clonerai per la prima volta, otterrai un ramo chiamato mastere un telecomando chiamato origin(da cui hai clonato) con il master locale impostato per tracciare il master sull'origine. Una volta impostato, puoi semplicemente dire git pushe lo farà. Il comando più lungo è disponibile in caso di necessità (ad esempio, git pushpotrebbe essere inviato al repository pubblico ufficiale e git push review masterpuò essere utilizzato per inviare un telecomando separato utilizzato dal team per rivedere il codice). Puoi impostare il tuo ramo come ramo di tracciamento usando il--set-upstreamopzione del git branchcomando.

Ho sentito che git (a differenza della maggior parte delle altre app che ho usato) è meglio compreso da dentro. Una volta compreso il modo in cui i dati vengono archiviati e gestiti all'interno del repository, i comandi e ciò che fanno diventano cristallini. Sono d'accordo con te sul fatto che ci sia un po 'di elitarismo tra molti gitutenti, ma ho anche scoperto che con gli utenti UNIX c'era una volta, e valeva la pena scavarli oltre per imparare il sistema. In bocca al lupo!

— Noufal Ibrahim
fonte

8

Potresti voler aggiungere una nota nel tuo paragrafo sui trasporti spiegando che git@github.com:peter/first_app.gitè la scpsintassi di stile per gli URL ssh in git. Un altro punto è che, per impostazione predefinita, la configurazione upstream di masternon influisce sul comportamento di a git push meno che non sia stato push.defaultimpostato su tracking(o upstreamnelle versioni successive) - Ho pubblicato un post sul blog su questa fonte di confusione: longair.net/blog/2011 /

— 02/27

1

Una piccola correzione a quel commento - senza push.defaultla configurazione upstream verrebbe utilizzata per trovare il telecomando predefinito quando si usa git push, ma non influirebbe sulla mappatura dei riferimenti.

— Mark Longair,

1

Mi chiedo perché il "dentro e fuori", come al solito, la "scatola nera" sia molto facile da imparare ... è come un approccio dall'alto verso il basso, con la parte superiore - l'interfaccia - ciò che inserisci e ciò che ottieni, molto ben definito e, si spera, anche semplice. Tutto ciò di cui un utente deve preoccuparsi è l '"Interfaccia", e davvero non ha bisogno di sapere cosa c'è dentro. Se l'utente vuole saperne di più, il modo speciale di implementazione, è bene saperlo, ma di solito è facoltativo.

— polarità

3

Apropos boxen nero contro rovescio. Git è la prima cosa che ho incontrato che in realtà è stato più facile da imparare a fondo piuttosto che dall'interfaccia. È discutibile che sia la strada giusta o meno. Sto solo dicendo che dentro e fuori è più efficace quando si tratta di git.

— Noufal Ibrahim,

9

"git è come UNIX. Facile da usare ma pignolo sui suoi amici." È così fantastico che lo voglio stampato su una maglietta.

— proflux,

41

Aggiornamento: nota che la risposta attualmente accettata perpetua un malinteso comune sul comportamento di git push, che non è stato corretto nonostante un commento che lo sottolinea.

Il tuo riepilogo di quali telecomandi sono - come un nickname per l'URL di un repository - è corretto.

Quindi perché l'URL non git: //git@github.com/peter/first_app.git ma nell'altra sintassi: che sintassi è? Perché deve finire con .git? Ho provato a non usare .git alla fine e funziona anche. Se non .git, cos'altro può essere? Il git al principiante sembra essere un account utente sul server git?

I due URL che hai menzionato indicano che dovrebbero essere utilizzati due diversi protocolli di trasporto. Quello che inizia con git://è per il protocollo git, che di solito è usato solo per l'accesso in sola lettura ai repository. L'altro git@github.com:peter/first_app.git, è uno dei diversi modi di specificare l'accesso a un repository su SSH: questa è la "sintassi in stile scp" descritta nella documentazione . Il fatto che il nome utente nella sintassi in stile scp gitsia dovuto al modo in cui GitHub si occupa dell'identificazione degli utenti, essenzialmente quel nome utente viene ignorato e l'utente viene identificato in base alla coppia di chiavi SSH che hanno usato per autenticare.

Per quanto riguarda la verbosità di git push origin master, hai notato che dopo la prima spinta, puoi semplicemente farlo git push. Ciò è dovuto a una serie di impostazioni predefinite difficili da ricordare ma generalmente utili :)

Se non viene specificato alcun telecomando, viene utilizzato il telecomando configurato per il ramo corrente ( remote.master.urlnel tuo caso). Se questo non è impostato, originviene utilizzato.
Se non c'è "refspec" (es master . master:my-experiment, Ecc.), Git ha come impostazione predefinita il push su ogni ramo locale che ha lo stesso nome di un ramo sul telecomando. Se hai solo un ramo chiamato masterin comune tra il tuo repository e quello remoto, sarà come spingerti mastersul telecomando master.

Personalmente, poiché tendo ad avere molti rami di argomenti (e spesso diversi telecomandi) uso sempre il modulo:

git push origin master

... per evitare di spingere accidentalmente altri rami.

In risposta ai tuoi commenti su una delle altre risposte, mi sembra come se stia imparando a conoscere git in modo molto efficace dal basso verso il basso: hai scoperto che le impostazioni predefinite funzionano e la tua domanda si chiede perché;) A sii più serio, git canessere utilizzato essenzialmente semplicemente come SVN, ma conoscere un po 'di telecomandi e rami significa che puoi usarlo in modo molto più flessibile e questo può davvero cambiare il modo in cui lavori in meglio. La tua osservazione su un corso di semestre mi fa pensare a qualcosa che Scott Chacon ha detto in un'intervista podcast: agli studenti vengono insegnati tutti i tipi di strumenti di base in informatica e ingegneria del software, ma molto raramente il controllo delle versioni. I sistemi di controllo di versione distribuito come git e Mercurial sono ora così importanti e così flessibili che varrebbe la pena insegnare su di essi per dare alle persone una buona base.

La mia opinione è che con gitquesta curva di apprendimento ne sia assolutamente valsa la pena: lavorare con molti rami di argomenti, unirli facilmente e spingerli e spostarli tra i diversi repository è incredibilmente utile quando si diventa sicuri del sistema. È solo un peccato che:

La documentazione principale per Git è così difficile da analizzare per i nuovi arrivati. (Anche se direi che se tu per Google quasi per qualsiasi domanda git, materiale tutorial utile (o Stack Overflow risponde :)) arriva oggi.)
Ci sono alcuni comportamenti strani in git che sono difficili da cambiare ora perché molti script possono fare affidamento su di essi, ma sono confusi per le persone.

— Mark Longair
fonte

Penso che il libro pro git sia una risorsa eccellente e facilmente comprensibile per i nuovi arrivati. Leviga notevolmente la curva di apprendimento. Inoltre, penso che provare a "mappare" SVN e altri concetti centralizzati su git renderà la strada più dura piuttosto che più liscia. Un ripristino completo è un modo più rapido e semplice nella mia esperienza.

— Noufal Ibrahim,

@Noufal Ibrahim: sono d'accordo su tutti i tuoi punti. Non stavo cercando di suggerire di "mappare" i concetti SVN su quelli git, dato che conosco l'orribile confusione che può causare - ci sono modi migliori per insegnare git dall'alto.

— Mark Longair,

9

Dai un'occhiata alla sintassi per l'aggiunta di un repository remoto.

git remote add origin <url_of_remote repository>

Esempio:

git remote add origin git@github.com:peter/first_app.git

Analizziamo il comando:

git remote è usato per gestire i server centrali per l'hosting dei repository git.

Forse stai usando Github per il tuo repository centrale. Vi farò un esempio e spiegherò il comando git remote add origin origin

Supponiamo di lavorare con GitHub e BitBucket per i server centrali per i repository git e di aver creato repository su entrambi i siti Web per il mio progetto per la prima app .

Ora, se voglio inviare le mie modifiche a entrambi questi server git, dovrò dire a git come raggiungere questi repository centrali. Quindi dovrò aggiungere questi,

Per GitHub

git remote add gh_origin https://github.com/user/first-app-git.git

E per BitBucket

git remote add bb_origin https://user@bitbucket.org/user/first-app-git.git

Ho usato due variabili (per quanto sia facile per me chiamarle variabili) gh_origin (gh FOR GITHUB) e bb_origin (bb per BITBUCKET) solo per spiegarti che possiamo chiamare origine tutto ciò che vogliamo.

Ora dopo aver apportato alcune modifiche dovrò inviare (push) tutte queste modifiche ai repository centrali in modo che altri utenti possano vedere queste modifiche. Quindi chiamo

Spingendo su GitHub

git push gh_origin master

Spingendo a BitBucket

git push bb_origin master

gh_origin detiene il valore di https://github.com/user/first-app-git.git e bb_origin detiene il valore di https: //user@bitbucket.org/user/first-app-git.git

Queste due variabili mi stanno semplificando la vita

come ogni volta che devo inviare le mie modifiche al codice, devo usare queste parole invece di ricordare o digitare l'URL per lo stesso.

La maggior parte delle volte non vedrai nulla tranne l' origine, poiché la maggior parte delle volte ti occuperai di un solo repository centrale come Github o BitBucket per esempio.

— Sig. Suryaa Jha
fonte

5

Alla .gitfine del nome del repository è solo una convenzione. In genere, sui server git i repository sono conservati nelle directory denominate project.git. Il client e il protocollo git onorano questa convenzione testando project.gitsolo quando projectè specificato.
git://git@github.com/peter/first_app.gitnon è un URL git valido. i repository git possono essere identificati e accessibili tramite vari schemi url qui specificati . git@github.com:peter/first_app.git è l' sshURL menzionato in quella pagina.
gitè flessibile. Ti consente di tracciare il tuo ramo locale contro quasi tutti i rami di qualsiasi repository. Mentre masteril tracciamento origin/master(il ramo predefinito locale) (il ramo predefinito remoto) è una situazione popolare, non è universale. Molte volte potresti non volerlo fare. Questo è il motivo per cui il primo git pushè così dettagliato. Indica a git cosa fare con il masterramo locale quando si esegue un git pullo un git push.
L'impostazione predefinita per git pushe git pullè lavorare con il telecomando del ramo corrente. Questo è un valore predefinito migliore del master originale. Il modo in cui git push determina questo è spiegato qui .

git è abbastanza elegante e comprensibile ma c'è una curva di apprendimento da percorrere.

— Anshul
fonte

1

Come ho commentato sull'altra risposta, nella configurazione predefinita di git, git pushnon usa le variabili di configurazione impostate git branch/checkout --trackper determinare a quale riferimento remoto premere. Hai ragione che Git Pull li usa, comunque.

— Mark Longair,

0

Git remote aggiungi origine:

Centralizza il codice sorgente su altri progetti, è sviluppato sulla base di Linux, completa l'open source e rende il codice utile agli altri utenti git. Lo chiamiamo come riferimento

Inserisce il codice nel repository git usando l'URL remoto dell'hub git.

— SaiPutta
fonte