Perché dovrei spingere se lavoro da solo in un repository locale?

Sto interagendo con Git tramite GitHub per Windows , il che è divertente poiché non spingerò mai il mio repository su GitHub. Ci sto lavorando da solo ed è destinato a essere utilizzato solo da me. Ho notato che i miei commit sono elencati sotto "commit non sincronizzati" e sotto "storia" dice "no commit". Il che mi porta alla domanda: cosa otterrò spingendo tranne i miei impegni elencati nella "storia"?

Tecnicamente hai ragione - non c'è bisogno di spingere se non condividi il codice con nessuno.

Poi di nuovo, il tuo laptop ha un disco rigido creato dal miglior offerente. La tua casa potrebbe bruciarsi prima che il disco rigido si guasti. Potresti voler esaminare il tuo codice da remoto. O addirittura condividerlo con qualcuno.

Ora, con Github, richiedono che tutto sia pubblico o che tu debba pagare per i repository privati. Quindi, se vuoi tenerlo per te, potresti voler dare un'occhiata a bitbucket che ti permetterà di fare git ma offre anche repository privati ​​gratuiti.

Un'altra opzione sarebbe quella di salvare il repository git da qualche parte di cui è stato eseguito il backup in remoto. Ma ci sono pochi vantaggi nel fare questo piuttosto che usare un provider SCM cloud in questi giorni.

C'è un altro motivo che vorresti spingere in un repository (anche se è, in un modo o nell'altro, locale): le workstation .

Non ti conosco, ma lavoro su 4 computer diversi (1 PC a casa, 1 laptop, 1 PC Office e 1 laptop Office) e l'invio di modifiche a un server Git correttamente configurato nel server della mia azienda rende la sincronizzazione veloce e indolore. Dato che Git è un DVCS, questo offre questo vantaggio: non si tratta solo di backup, ma tutti i diversi codebase su cui sto lavorando possono essere facilmente uniti, controllati e analizzati.

Può essere locale se, ad esempio, il tuo PC di casa è il "server" (o l'origine) e hai un laptop di casa, in questo modo puoi mantenerti facilmente sincronizzato.

Sidenote : le persone spesso dicono "Preferirei usare Dropbox (o qualsiasi altro servizio di sincronizzazione)". Le enormi quantità di oggetti di un repository Git rendono ridicolo usare Dropbox in questo modo. È un'opzione, ma non direi una buona.

Come SCM distribuito, git distingue tra i concetti "crea un'istantanea della copia di lavoro" (commit) e "sincronizza repository" (push / pull / fetch).

Se hai sempre un solo clone locale del tuo repository, non ha senso spingerlo. Tuttavia, con GitHub, è fare un altro clone (quello su GitHub), e spingendo le modifiche non ha almeno un vantaggio: il backup. Se il tuo computer muore, hai ancora tutto spinto su Github.

Naturalmente, questo non è lo scopo principale di Github; github è destinato alla condivisione del codice, quindi se il tuo progetto è su github, puoi consentire ad altri di estrarre da lì, clonare il tuo progetto, agire su richieste pull dai loro cloni o persino dare ad altri fidati l'accesso push al tuo repository.

Un altro motivo per spingere è se si utilizzano diversi cloni locali. Questo può essere utile per varie cose: ad esempio, potresti voler lavorare su due diversi rami contemporaneamente, oppure potresti provare operazioni potenzialmente distruttive sul tuo repository; se tutto funziona come previsto, mantieni il clone modificato (o rispedisci le modifiche al repository originale), ma se le cose vanno a sud, puoi semplicemente eliminare il clone incasinato e tornare a quello originale (che è ancora invariato) .

Alcune persone usano persino git per la distribuzione: anche la versione di produzione è un repository git e l'aggiornamento a una versione più recente è una questione di recupero e checkout (ovviamente, funziona solo se non è necessario un passaggio di generazione). Non lo consiglierei necessariamente per cose serie, ma per piccole cose è una soluzione semplice e pragmatica.