Sto interagendo con Git attraverso GitHub per Windows , il che è divertente dato che non spingerò mai il mio repository su GitHub. Ci sto lavorando da solo ed è destinato ad essere usato solo da me. Ho notato che i miei commit sono elencati sotto "commit non sincronizzati" e sotto "history" dice "no commit". Il che mi porta alla domanda: cosa otterrò spingendo tranne i miei commit elencati sotto "cronologia"?
Sei tecnicamente corretto - non c'è bisogno di spingere se non stai condividendo il codice con nessuno.
Poi di nuovo, il tuo laptop ha un disco rigido creato dal miglior offerente. La tua casa potrebbe bruciare prima che l'hard disk non funzioni. Potresti voler controllare il tuo codice da remoto. O anche condividerlo con qualcuno.
Ora, con Github, richiedono che tutto sia pubblico o che tu debba pagare per gli archivi privati. Quindi, se vuoi tenerlo per te, potresti voler controllare bitbucket che ti permetterà di fare git, ma include anche repository privati gratuiti.
Un'altra opzione potrebbe essere quella di salvare il repository git da qualche parte di cui è stato eseguito il backup da remoto. Ma ci sono pochi vantaggi a fare questo piuttosto che usare un provider SCM di cloud in questi giorni.
C'è un'altra ragione per cui vorresti spingere su un repository (anche se è, in un modo o nell'altro, locale): workstation .
Non so voi, ma lavoro su 4 computer diversi (1 PC a casa, 1 laptop, 1 Office PC e 1 laptop Office) e le modifiche a un server Git configurato correttamente nel server della mia azienda rendono sincronizzazione veloce e indolore. Dato che Git è un DVCS, questo è un vantaggio: non sono solo i backup, ma tutti i diversi database che sto lavorando possono essere facilmente uniti, controllati e analizzati.
Può essere locale se, ad esempio, il PC di casa è il "server" (o l'origine) e si dispone di un laptop domestico - in questo modo è possibile rimanere facilmente sincronizzati.
Sidenote : le persone spesso dicono "Preferisco usare Dropbox (o qualsiasi altro servizio di sincronizzazione)". Le enormi quantità di oggetti che un repository Git ha reso ridicolo usare Dropbox in questo modo. È un'opzione, ma non ne direi una buona.
Come SCM distribuito, git distingue tra i concetti "crea un'istantanea della copia di lavoro" (commit) e "repository di sincronizzazione" (push / pull / fetch).
Se hai sempre un solo clone locale del tuo repository, allora non ha senso spingere. Tuttavia, con github, tu fai hai un altro clone (quello su github), e spingendo le tue modifiche c'è almeno un vantaggio: il backup. Se il tuo computer muore, hai ancora tutto spinto finora su github.
Naturalmente, questo non è lo scopo principale di Github; github è inteso per la condivisione del codice, quindi se il tuo progetto è su github, puoi consentire ad altri di tirare da lì, clonare il tuo progetto, agire sulle richieste di pull dai loro cloni o persino dare ad altri di fiducia l'accesso al tuo repository.
Un altro motivo per spingere è se usi diversi cloni locali. Questo può essere utile per varie cose: ad esempio, potresti voler lavorare su due rami diversi allo stesso tempo, oppure potresti voler provare eventuali operazioni distruttive sul tuo repository; se tutto funziona come previsto, si mantiene il clone modificato (o si spinge le modifiche al repository originale), ma se le cose vanno a sud, è sufficiente eliminare il clone incasinato e tornare a quello originale (che è ancora invariato) .
Alcune persone usano anche git per la distribuzione: la versione di produzione è anche un repo git, e l'aggiornamento a una versione più recente è una questione di recupero e estrazione (ovviamente, funziona solo se non è necessario un passo di costruzione). Non lo consiglierei necessariamente per cose serie, ma per le piccole cose è una soluzione semplice e pragmatica.