27 suggerimenti essenziali per gli utenti di Git e GitHub

Sebbene gli utenti di Git abbiano dozzine di guide introduttive tra cui scegliere e GitHub offra una serie di guide proprie, non è ancora facile trovare una raccolta di suggerimenti utili per gli sviluppatori che vogliono lavorare in modo più intelligente con Git e GitHub. Risolviamolo.

Per quelli di voi che non hanno familiarità con Git o GitHub, i prossimi paragrafi forniranno informazioni sufficienti per comprendere i suggerimenti. Elencheremo circa una dozzina di risorse utili alla fine di questo articolo.

Git è un sistema di controllo della versione distribuito, originariamente scritto da Linus Torvalds nel 2005 per e con l'aiuto della comunità del kernel Linux. Non sono qui per venderti su Git, quindi ti risparmierò il discorso su quanto sia veloce, piccolo, flessibile e popolare, ma dovresti sapere che quando cloni un repository Git ("repo", in breve) , ottieni l'intera cronologia delle versioni sul tuo computer, non solo un'istantanea da un ramo alla volta.

Git è iniziato come uno strumento da riga di comando, adattandosi alla sua origine nella comunità del kernel Linux. Puoi ancora usare la riga di comando Git, se lo desideri, ma non è necessario. In particolare, se utilizzi GitHub come host, puoi utilizzare il client desktop GitHub gratuito su Windows o Mac. D'altra parte, la riga di comando Git funzionerà per qualsiasi host e viene preinstallata sulla maggior parte dei sistemi Mac e Linux.

Solo tu puoi decidere se ti senti più a tuo agio utilizzando la riga di comando o un client nativo con un'interfaccia utente grafica. Se ti piace una GUI, oltre al client GitHub (Windows e Mac), potresti prendere in considerazione SourceTree (Windows e Mac, gratuito), TortoiseGit (solo Windows, gratuito) e Gitbox (solo Mac, $ 14,99). Oppure puoi usare un editor o un IDE che supporti Git internamente (vedi suggerimento n. 11).

Suggerimento Git / GitHub n. 1: clona quasi tutto

Ci sono molti progetti interessanti disponibili da GitHub e altri repository Git pubblici che puoi clonare liberamente sul tuo computer. Perché dovresti farlo? Uno dei motivi è imparare qualcosa sullo stile di codifica, la pratica e gli strumenti in una lingua di interesse, incluso lo stile di commento del registro di commit (vedere il suggerimento n. 4). Una seconda ragione è imparare come un determinato progetto raggiunge i suoi obiettivi. Una terza ragione, se la licenza ti permettesse di farlo e avesse senso per i tuoi scopi, sarebbe incorporare il progetto nella tua impresa o prodotto. A proposito, ricontrolla la licenza in modo da non incorrere in problemi di conformità in seguito.

La definizione di git clonedalla pagina di manuale:

Clona un repository in una directory appena creata, crea rami di tracciamento remoto per ogni ramo nel repository clonato (visibile usando git branch -r) e crea ed estrae un ramo iniziale che viene biforcato dal ramo attualmente attivo del repository clonato.

Dopo il clone, un semplice git fetchsenza argomenti aggiornerà tutti i rami di tracciamento remoto e un git pullsenza argomenti unirà inoltre il ramo principale remoto nel ramo principale corrente, se presente.

Suggerimento Git / GitHub n. 2: tirare frequentemente

Uno dei modi più semplici per creare confusione con Git (e in effetti, con qualsiasi sistema di controllo della versione) è consentire ai file di non essere sincronizzati. Se lo fai git pullspesso, manterrai aggiornata la tua copia del repository e avrai l'opportunità di unire il tuo codice modificato con le modifiche di altri mentre l'unione è facile da capire e da realizzare, idealmente, quando è così facile che può essere fatto automaticamente. Un corollario di questo suggerimento è controllare lo stato del tuo progetto. Molti client Git ti mostreranno automaticamente quando è necessario aggiornare per rimanere aggiornati.

Suggerimento Git / GitHub n. 3: impegnati presto e spesso

Un commit è un aggiornamento granulare di un progetto, che include una o più modifiche a uno o più file. Consideralo come una registrazione di un'unità di lavoro completata, che può essere applicata o rimossa dal progetto come un tutto logico. Esegui il commit di ogni modifica logica che completi, anche prima di testarla. I commit si applicano solo al tuo repository locale. Vedere i suggerimenti n. 4 e 5 per i corollari di questo suggerimento.

La definizione di git commitdalla pagina di manuale:

Memorizza il contenuto corrente dell'indice in un nuovo commit insieme a un messaggio di log dell'utente che descrive le modifiche.

Suggerimento Git / GitHub n. 4: commenta i tuoi commit come faresti per commentare gli altri

Esistono 10 tipi di programmatori: quelli che commentano i loro commit e quelli che non lo fanno. (Vecchia barzelletta. Suggerimento: quale base sto usando?)

Ammetto liberamente di essere un pignolo per buoni messaggi di log dei commit. Ho impostato i miei repository per richiedere messaggi per ogni commit e sono noto che inviano messaggi fastidiosi a tarda notte quando i commit arrivano con i log nell'ordine "xx". Se sei il tipo di sviluppatore che pensa (1) il codice dovrebbe parlare da solo e (2) i commenti in linea sono molto più importanti dei registri delle modifiche, prova a clonare un repository che non hai mai visto prima e a identificare il commit recente che potrebbe aver causato l'ultimo problema pubblicato senza leggere tutto il codice. Come puoi vedere, i log di commit accurati sono il doppio più buoni.

Suggerimento Git / GitHub n. 5: esegui il push quando le modifiche vengono testate

Il peggior bug relativo a Git di cui abbia mai avuto la sfortuna di conoscere si è verificato quando una società di outsourcing è passata da Subversion ma non ha addestrato i suoi sviluppatori sulla differenza tra controllo del codice sorgente distribuito e controllo del codice sorgente centralizzato. Circa un mese dopo, il progetto ha sviluppato strani bug che nessuno sembrava riuscire a rintracciare. Alle riunioni quotidiane di stand-up, gli sviluppatori responsabili dell'area dell'applicazione che si comportava in modo anomalo protestavano: "L'ho risolto due settimane fa!" o accusare un altro sviluppatore di non preoccuparsi di applicare le modifiche che avevano così attentamente controllato.

Alla fine, qualcuno ha identificato il problema e ha insegnato a tutti gli sviluppatori come e quando eseguire pushi commit: in breve, ogni volta che i commit vengono testati con successo in una build locale. L'azienda ha quindi organizzato un merge fest di due giorni prima di poter creare e distribuire il prodotto integrato aggiornato.

Suggerimento Git / GitHub n. 6: ramifica liberamente

Uno dei maggiori vantaggi che Git ha rispetto ad altri sistemi di controllo della versione è che l'unione di solito funziona bene, almeno in parte perché Git sceglie automaticamente il miglior antenato comune da usare per un'unione. La maggior parte degli sviluppatori di software deve iniziare a creare rami nei propri progetti più spesso. Dovrebbe essere un evento quotidiano di routine, non oggetto di un angoscioso incontro strategico a tutte le mani. È probabile che, quando il progetto di filiale è completo, accettato e pronto per passare al progetto principale, l'unione non presenterà problemi insormontabili.

So che richiede qualche aggiustamento, soprattutto se sei rimasto bloccato in un'azienda che esegue il controllo del codice sorgente con CVS. Ma provalo. È molto meglio che avere clienti che vedono accidentalmente il tuo codice sperimentale incompiuto quando il progetto trunk deve essere pubblicato a causa di un bug di rottura. (Questo articolo spiega bene la ramificazione e l'unione di base.)

Suggerimento Git / GitHub n. 7: unisci attentamente

Mentre le fusioni con Git di solito funzionano bene, se le fai senza pensare, potresti occasionalmente incontrare difficoltà. Il primo passo è assicurarsi di non avere modifiche non salvate. Dalla git mergepagina del manuale:

Prima di applicare modifiche esterne, dovresti mettere il tuo lavoro in buona forma e impegnato a livello locale, in modo che non venga distrutto in caso di conflitti. Vedi anche git-stash.

Vedi anche suggerimento n. 8.

Anche se tutto va a sud durante un git merge, non sei lavato:

Se hai provato un'unione che ha provocato conflitti complessi e desideri ricominciare da capo, puoi eseguire il ripristino con git merge —abort.

Il comando successivo a git mergeè di solito git mergetool, supponendo che ti piaccia utilizzare una GUI per l'unione. Se preferite il metodo di vecchia scuola, è possibile modificare i file in conflitto con il vostro editor di programmazione preferito, rimuovere completamente i <<<<<<<, =======e >>>>>>>le linee, salvare i file rivisti, e git addogni file viene confermato.

Suggerimento Git / GitHub n. 8: Stash prima di cambiare ramo

Il flusso di lavoro di uno sviluppatore di software è raramente lineare. Gli utenti hanno la faccia tosta di segnalare bug, i manager hanno l'audacia di dare la priorità ai ticket diversi da quello su cui hai scelto di lavorare e tu stesso potresti cambiare idea su ciò che vuoi fare.

Eccoti qui, con tre file sottoposti a commit per una versione e un quarto file in uno stato modificato ma non funzionante. (Il git statuscomando ti dirà tutto questo se non ti ricordi dove ti trovavi.) All'improvviso devi lavorare su una correzione di bug in una versione di produzione. Devi cambiare ramo subito, ma non puoi. La tua directory di lavoro è sporca e hai due ore di lavoro che non vuoi perdere.

Entra git stash. Ecco! Ora tutte le modifiche sono archiviate in un ramo WIP (work in progress) e puoi passare al ramo di produzione dalla tua directory pulita. Quando hai finito, torna al punto in cui eri git stash apply.

Suggerimento Git / GitHub n. 9: utilizza i riepiloghi per condividere frammenti e paste

Le "sintesi" di GitHub, frammenti di codice condiviso, non sono una funzionalità di Git, ma utilizzano Git. Tutti i gist sono repository Git e GitHub Gist semplifica la condivisione. Puoi cercare Gist per riepiloghi pubblici per argomento, linguaggio di programmazione, stato biforcuto e stato speciale. Puoi anche creare elenchi segreti e condividerli tramite URL.

Suggerimento Git / GitHub n. 10: esplora GitHub

Molti progetti open source interessanti hanno repository su GitHub. Esplora GitHub fornisce un'interfaccia di navigazione per trovarne alcuni, ma soprattutto è più facile digitare alcune lettere del nome del progetto nella casella di ricerca per trovare i suoi repository. Ad esempio, digita jqo backo angper trovare tre dei principali framework JavaScript open source.

Suggerimento Git / GitHub n. 11: contribuisci a progetti open source

Finché navighi in progetti open source, perché non contribuire a loro? Non è così difficile come potresti pensare e imparerai molto. Ad esempio, potresti clonare il progetto jquery / jquery (jQuery Core) e sfogliare README.MD. In alto vedrai:

Nello spirito dello sviluppo di software open source, jQuery incoraggia sempre il contributo del codice della comunità. Per aiutarti a iniziare e prima di iniziare a scrivere codice, assicurati di leggere attentamente queste importanti linee guida sui contributi ...

Questo è seguito da tre collegamenti. Il primo dei tre ti farà iniziare abbastanza velocemente. Non tutti i progetti open source presentano il piano in modo così chiaro, ma tutti ci provano.

Comprendi la differenza tra essere un contributore e un committer. Un collaboratore ha firmato gli accordi richiesti e ha messo a disposizione un contributo per il progetto. Un committer ha il potere di impegnare effettivamente il contributo offerto al repository del progetto. Poiché ci sarà un ritardo mentre un committer verifica il tuo contributo e non vorrai legare il tuo ramo master, dovresti apportare le modifiche in un altro ramo (vedi suggerimento n. 6) prima di inviare una richiesta pull (vedi suggerimento n. . 16).