GitHub è diventato la pietra angolare di tutto il software open source. Gli sviluppatori lo adorano, collaborano e creano costantemente progetti fantastici. Oltre ad ospitare il nostro codice, l'attrazione principale di GitHub è quella di utilizzarlo come strumento collaborativo. In questo tutorial, esploriamo alcune delle più utili funzionalità di GitHub, specialmente per lavorare in team, rendendo tutto più efficiente, produttivo e, soprattutto, divertente!
Github e Software Collaboration
Una cosa che trovo molto utile è l'integrazione di Github Wiki nel progetto del codice sorgente principale.
Questo tutorial presume che tu abbia già familiarità con Git, il sistema di controllo delle versioni distribuito open source, creato da Linus Torvalds nel 2005. Se hai bisogno di una revisione o di una ricerca su Git, visita il nostro corso di screencast precedente o anche alcuni post. Inoltre, dovresti già avere un account Github e hai fatto alcune funzioni di base come la creazione di un repository e le modifiche a Github. Altrimenti, vai su altri tutorial precedenti.
Nel mondo dei progetti software, è inevitabile che ci troveremo a lavorare in un team per consegnare un progetto. Per questo tutorial su Github e la collaborazione del team, esploreremo alcuni degli strumenti più comuni di cui abbiamo generalmente bisogno quando lavoriamo con i team di software. Gli strumenti discussi sono:
Aggiunta di membri del team - Organizzazione e collaboratori
Pull Requests - Invio e fusione
Monitoraggio dei bug - Problemi di Github
analitica - Grafici e rete
Gestione di progetto - Trello & Pivotal Tracker
Integrazione continua - Travis CI
Revisione del codice - Commenti lineari e query URL
Documentare - Wiki e Hubot
Preferisci uno Screencast?
Se preferisci uno screencast per un walk-through visivo, salta subito sotto per visualizzarlo e fai riferimento a questo tutorial come note a margine:
Scarica video
Strumento 1: aggiunta di membri del team
Ci sono generalmente due modi per configurare Github per la collaborazione del team:
organizzazioni - Il proprietario dell'organizzazione può creare molti team con diversi livelli di autorizzazione per vari repository
collaboratori - Il proprietario del repository può aggiungere collaboratori con accesso Read + Write per un singolo repository
organizzazioni
Se si sta supervisionando diversi team e si desidera impostare livelli di autorizzazione diversi per ogni squadra con vari membri e aggiungere ciascun membro a repository differenti, l'organizzazione sarebbe l'opzione migliore. Qualsiasi account utente Github può già creare Organizzazioni libere per repository di codice open source. Per creare un'organizzazione, accedi alla pagina delle impostazioni della tua organizzazione:
Per accedere alla pagina delle squadre per la tua organizzazione, puoi semplicemente andare a http://github.com/organizations/[organization-name]/teams per vederli o anche per visitarli https://github.com/organizations/[organization-name]/teams/new creare nuovi team con membri di 3 diversi livelli di autorizzazione come:
Pull Only: Recupera e Unisci con un altro repository o una copia locale. Accesso di sola lettura.
Spingi e tira: (1) insieme all'aggiornamento del repository remoto. Leggi + Scrivi accesso.
Push, Pull & Administrative: (1), (2) insieme ai diritti sulle informazioni di fatturazione, alla creazione di team e all'annullamento degli account dell'organizzazione. Leggi + Scrivi + Accesso amministratore
collaboratori
I collaboratori sono abituati a dare entrambi Leggi + Scrivi accesso a un singolo repository di proprietà di un account personale. Per aggiungere Collaboratori, (altri account personali Github) basta andare su https://github.com/[username]/[repo-name]/settings/collaboration:
Fatto ciò, ciascun Collaboratore vedrà una modifica dello stato di accesso nella pagina del repository. Dopo aver accesso in scrittura al repository, possiamo fare a git clone, lavorare sui cambiamenti, fare a tira fuori per recuperare e unire eventuali modifiche nel repository remoto e, in ultima analisi spingere, per aggiornare il repository remoto con le nostre modifiche:
Strumento 2: richiama richieste
Le richieste di pull sono un modo fantastico per contribuire a un repository in modo indipendente rilanciandolo. Alla fine della giornata, se lo desideriamo, possiamo inviare una richiesta di pull al proprietario del repository per unire le nostre modifiche al codice. La richiesta pull in sé può quindi attivare discussioni per la qualità del codice, le funzionalità o anche la strategia generale.
Passiamo ora ai passaggi di base per una richiesta di pull.
Avvio di una richiesta di pull
Ci sono due modelli di richiesta pull in Github:
Modello Fork & Pull - Utilizzato in un repository pubblico per il quale non abbiamo accesso push
Condividi modello di repository - Utilizzato in un repository privato per il quale abbiamo accesso push. La forcella non è richiesta in questo caso.
Qui vediamo il flusso di lavoro tra due utenti (repo-proprietario e biforcuta-repo-proprietario) per il modello Fork and Pull:
Identificare il repository Github a cui si desidera contribuire e fare clic sul pulsante "Fork" per creare un clone del repository nel proprio account Github:
Questo creerà una copia esatta del repository nel tuo account
Scegli l'URL SSH in modo che richieda la passphrase della chiave SSH invece del nome utente e della password ogni volta che lo fai spingere o tira fuori. Successivamente, cloneremo questo repository sul nostro computer locale:
$ git clone [ssh-url] [nome-cartella] $ cd [nome-cartella]
Generalmente, creeremo un nuovo ramo git per ogni nuova funzionalità. Questa è una buona pratica perché in futuro se aggiorneremo ulteriormente il ramo dopo alcune discussioni, la richiesta di pull verrà automaticamente aggiornata. Creiamo un nuovo ramo per fare una modifica molto semplice per modificare il readme.md file:
$ git checkout -b [nuova funzionalità]
Dopo aver apportato le aggiunte pertinenti per creare le nuove funzionalità, eseguiremo semplicemente le nuove modifiche e il checkout al ramo principale di git:
A questo punto, inseriremo il ramo nel repository remoto. Per questo controlleremo innanzitutto il nome del ramo con la nuova funzione e gli alias del repository remoto git. Quindi applicheremo le modifiche usando git push [git-remote-alias] [nome-ramo]:
Nella nostra pagina Github del repository con fork, passeremo al branch con la nuova funzione e quindi clicchiamo sul pulsante "Pull Request".
Dopo aver inviato la richiesta di pull, ci porterà direttamente alla pagina di richiesta di pull del repository originale. Vedremo la nostra richiesta di pull, sia come nuovo problema che come nuova richiesta di pull.
Dopo la discussione, potrebbe essere possibile che il proprietario del repository biforcato possa voler aggiungere modifiche alla nuova funzione. In questo caso, effettueremo il checkout allo stesso ramo nel nostro computer locale, lo impegneremo e lo reindirizzeremo a Github. Quando visitiamo la pagina di richiesta pull del repository originale, verrà automaticamente aggiornata!
Unione di una richiesta di pull
Se sei il proprietario del repository originale, ci sono due modi per unire una richiesta pull in arrivo:
Fusione diretta su Github: Se ci stiamo unendo direttamente in Github, assicurati che non ci siano conflitti ed è pronto per essere unito al ramo principale. Il proprietario del repository originale può semplicemente fare clic sul pulsante verde "Unisci pull request" per farlo:
Unendo le nostre macchine locali: Altre volte, potrebbero esserci conflitti di fusione e, facendo clic sul pulsante "Informazioni", Github avrà istruzioni chiare su come possiamo unire il ramo nella nostra macchina locale inserendo le modifiche dal ramo del collaboratore:
Esistono diversi modelli di ramificazione utilizzati per il controllo delle versioni nei team di sviluppo software. Ecco due popolari modelli di workflow git: (1) flusso di lavoro Github che ha un semplice modello di branching e utilizza le richieste pull e (2) Gitflow che ha una ramificazione più estesa. Il modello che alla fine verrà scelto cambierà sicuramente a seconda della squadra, del progetto e della situazione.
Strumento 3: monitoraggio dei bug
Le richieste di pull sono un modo fantastico per contribuire a un repository in modo indipendente rilanciandolo.
In Github, il centro per tutti i bug tracking sono i problemi. Anche se sono principalmente utili per il tracciamento dei bug, è utile utilizzare i problemi nei seguenti modi:
bugs: Cose che sono ovviamente rotte e hanno bisogno di correzioni
Caratteristiche: Fantastiche nuove fantastiche idee da implementare
Lista di cose da fare: Una lista di controllo degli elementi da completare
Esaminiamo alcune delle funzionalità di Issues:
etichette: Sono categorie colorate per ogni numero. Sono utili per filtrare i problemi di conseguenza.
Milestones: Sono categorie datate che possono essere associate a ciascun problema e sono utili per identificare quali problemi devono essere elaborati per la prossima versione. Inoltre, dal momento che i Milestones sono collegati ai problemi, aggiorna automaticamente la barra di avanzamento alla chiusura di ciascun problema associato.
Ricerca: Completa automaticamente la ricerca di entrambi i problemi e le pietre miliari
Assegnazione: Ogni problema può essere assegnato a una persona incaricata di risolvere il problema. È un'altra caratteristica utile per vedere su cosa dovremmo lavorare.
Chiusura automatica: Invia messaggi con Correzioni / Risolto o Chiudi / Chiude / Chiuso # [numero-problema] chiuderà automaticamente il problema.
menzioni: Chiunque può anche lasciare una nota semplicemente indicando #[edizione numero] nei loro messaggi Poiché i numeri dei numeri sono linkati, questo rende molto facile menzionare i problemi correlati durante la discussione.
Strumento 4: Analytics
È chiaro che possiamo accoppiare strettamente la nostra lista delle attività e gli aggiornamenti al nostro codice commettono.
Esistono due strumenti che forniscono informazioni su un repository: grafici e rete. Github Graphs fornisce una panoramica dei collaboratori e si impegna dietro ciascun repository di codice, mentre Github Network fornisce una visualizzazione su ciascun contributore e i relativi commit su tutti i repository biforcati. Queste analisi e grafici diventano molto potenti, specialmente quando si lavora in team.
grafici
I grafici forniscono analisi dettagliate come:
Contributori: Chi erano i contributori? E quante linee di codice hanno aggiunto o eliminato?
Attività di commit: In quali settimane i commit si sono svolti nell'ultimo anno?
Frequenza del codice: Quante linee di codice sono state impegnate per l'intero ciclo di vita del progetto?
punchcard: In quali momenti della giornata si svolgono solitamente i commit?
Rete
Github Network è un potente strumento che ti consente di visualizzare ogni commit di ogni contributore e in che modo sono correlati l'uno con l'altro. Quando guardiamo il visualizzatore nella sua interezza, vediamo ogni commit su ogni ramo di ogni repository che appartiene a una rete. Ipocrisia!
Strumento 5: gestione dei progetti
Sebbene i problemi di Github abbiano funzionalità di gestione dei progetti con problemi e milestone, alcuni team potrebbero preferire un altro strumento a causa di altre funzionalità o del flusso di lavoro esistente. In questa sezione vedremo come possiamo collegare Github con altri due strumenti di gestione del progetto popolari: Trello e Pivotal Tracker. Con gli hook di servizio Github, possiamo automatizzare l'attività di aggiornamento con commit, problemi e molte altre attività. Questa automazione aiuta non solo a risparmiare tempo, ma aumenta anche la precisione negli aggiornamenti per qualsiasi team di sviluppo software.
Github e Trello
Trello offre un modo semplice e visivo di gestire le attività. Utilizzando le metodologie di sviluppo del software Agile, le carte Trello possono emulare una semplice Kanban Board virtuale. Ad esempio, creeremo automaticamente una carta Trello ogni volta che viene effettuata una richiesta di pull con Gitn di servizio Github. Andiamo attraverso i passaggi!
Apri un account in Trello se non ne hai già uno e crea una nuova scheda Trello.
Vai al repository Github> Impostazioni> Ganci di servizio> Trello
Ottenere la GETTONE sotto Installare Note 1 con il collegamento ipertestuale fornito per l'autenticazione.
Sotto Installa Note n. 2, utilizza l'URL fornito per generare una struttura in formato json che ci dia il lista id per ogni carta Trello. BOARDID fa parte dell'URL quando visitiamo il forum a https://trello.com/board/[BOARD-NAME]/[BOARDID]. GETTONE può essere creato con il collegamento ipertestuale indicato in Installa Note n. 1.
Ritornati agli hook del servizio Github, inserisci il lista id e il gettone. Controlla Active, Test Hook e siamo pronti per ricevere aggiornamenti automatici ogni volta che viene richiesta Pull.
La prossima volta che ci sarà una richiesta di pull, la carta Trello di richiesta pull avrà automaticamente un nuovo oggetto!
Github e Pivotal Tracker
Pivotal Tracker è un altro strumento di gestione del progetto agile e leggero in cui la pianificazione basata sulla storia consente al team di collaborare facilmente reagendo all'istante a vari cambiamenti e progressi del progetto. Sulla base dei progressi attuali del team, può anche creare grafici per analizzare la velocità della squadra, la masterizzazione dell'iterazione, il burn-down del rilascio, ecc. In questo breve esempio, forniremo automaticamente una storia collegandola a un commit Github!
Crea un nuovo progetto nel Pivotal Tracker con una nuova storia che deve essere consegnata.
Vai a Profilo> Token API (direttamente in basso). Copia il token dell'API fornito.
Torna al repository Github> Impostazioni> Hook di servizio> Tracker pivotal. Incolla il token, seleziona Attivo e fai clic su Aggiorna impostazioni. Siamo tutti predisposti a consegnare automaticamente Pivotal Tracker Stories con Github Commits!
Infine, confermeremo le nostre modifiche e aggiungeremo l'id del tracker al messaggio di commit con il formato git commit -m "message [consegna #tracker_id]"
$ git add. $ git commit -m "Ganci Github e Pivotal Tracker implementati [consegna n. 43903595]" $ git push
Ora, quando torniamo al Pivotal Tracker, vedremo che la storia è stata consegnata automaticamente con link al commit Github esatto che mostra le modifiche al file!
Con questi esempi Trello e Pivotal Tracker, è chiaro che possiamo accoppiare strettamente la nostra lista delle attività e gli aggiornamenti al nostro codice commettono. Questo è un enorme risparmio di tempo quando si lavora in una squadra, e migliora la precisione quando si collegano le attività ai commit esatti. La buona notizia è che, se già usi altri strumenti di gestione del progetto come Asana, Basecamp e altri, puoi anche creare Service Hook in modo simile. Se non esistono Ganci di servizio esistenti per il tuo attuale strumento di gestione dei progetti, puoi persino crearne uno!
Strumento 6: integrazione continua
L'integrazione continua (CI) è una parte importante di tutti i progetti di sviluppo software che funzionano con i team. CI garantisce che, quando uno sviluppatore verifica il codice, una build automatizzata (compresi i test) rileva gli errori di integrazione il più rapidamente possibile. Ciò riduce decisamente gli errori di integrazione e rende l'iterazione rapida molto più efficiente. In questo esempio, vedremo come usare Travis CI con Github for CI per rilevare gli errori e consigliare l'unione quando supera tutti i test.
Impostazione di Travis CI
Utilizzeremo un semplice progetto "ciao-mondo" per node.js con grunt.js come strumento di compilazione per configurare un progetto Travis CI. Ecco i file nel progetto:
Il hello.js il file è il progetto del nodo. Qui lasceremo intenzionalmente un punto e virgola in modo che non passi lo strumento di generazione del grunt per il linting:
var http = require ('http'); http.createServer (function (req, res) res.writeHead (200, 'Content-Type': 'text / plain'); res.end ('Hello World in Node! \ n') // senza punto e virgola , questo non passerà il linting). listen (1337, '127.0.0.1'); console.log ('Server in esecuzione all'indirizzo http://127.0.1.11337/');
package.json denota le dipendenze:
"name": "hello-team", "description": "Una demo per github and travis ci per la collaborazione di squadra", "author": "nome "," version ":" 0.0.1 "," devDependencies ": " grunt ":" ~ 0.3.17 "," scripts ": " test ":" grunt travis --verbose "
Il gruntjs lo strumento di compilazione ha solo un'attività (linting) solo per semplicità:
.travis.yml è un file di configurazione di Travis che farà eseguire a Travis i nostri test:
lingua: node_js node_js: - 0.8
Quindi, accedi a Travis con il tuo account Github e attiva il gancio del repository nella scheda repository.
Se il passo precedente non innesca la build, allora dovremo impostare manualmente il hook di servizio. Per configurarlo manualmente, copia il token nella scheda del profilo.
Torna al repository Github per configurare gli hook del servizio Github Travis con il token.
Per la prima volta, dobbiamo fare un manuale spingere per attivare la prima build di Travis e se tutto è a posto, basta visitare http://travis-ci.org/[username]/[repo-name] per vedere lo stato della build come passeggero!
Travis CI con richieste di pull
Precedentemente, senza alcun elemento di configurazione nel processo di una richiesta pull, i passaggi sono stati eseguiti in questo modo (1) inviato test pull request (2) merge (3) per verificare se esso passa / non va. Con Travis CI collegato alle richieste di pull, saremo in grado di invertire i passaggi 2 e 3, aumentando ulteriormente il rapido processo decisionale sull'opportunità o meno di fondersi con Travis dandoci lo stato con ogni richiesta di pull. Vediamo come farlo accadere.
Invia una richiesta di pull con una build passante e Travis farà la sua magia per farti sapere che è bene fondersi anche prima della fusione
Se la Richiesta di Pull fallisce la costruzione, Travis ti avvertirà anche.
Se clicchiamo sul pulsante di allarme rosso, verrà anche collegato alla pagina di Travis per mostrarci i dettagli della build.
Travis CI con Github è immensamente utile per i team grazie alle build automatiche e alla notifica immediata. Certamente rende il ciclo di correzione degli errori molto più breve. Se stai usando Jenkins, un altro popolare strumento CI, sì puoi anche configurare ganci di servizio Github in modo molto simile.
Strumento 7: revisione del codice
Con ogni commit, Github consente un'interfaccia pulita per commenti generali o anche commenti specifici su una riga di codice. La possibilità di generare commenti o domande su ogni singola riga di codice è molto utile per eseguire revisioni di codice linea per riga. Per visualizzare i commenti in linea, attiva / disattiva la casella di controllo nella parte superiore di ciascun commit.
Esaminiamo alcuni pattern URL che possono essere utilizzati per aiutarci nella revisione del codice, fornendo rapidamente le differenze tra i commit:
Confronta rami / tag / SHA1 : usa il pattern URL https://github.com/[username]/[repo-name]/compare/[starting-SHA1]... [ending-SHA1]. Puoi fare lo stesso con branch o tag.
Confronta senza spazi bianchi : Inserisci ?w = 1 per confrontare gli URL
diff : Inserisci .diff agli URL di confronto per ottenere il git diff informazioni in testo semplice. Questo potrebbe essere utile per scopi di scripting.
toppa : Inserisci .toppa agli URL di confronto per ottenere il git diff informazioni formattate per invio di patch via email.
Collegamento di linea : Quando clicchiamo sul numero di linea su qualsiasi file, Github aggiungerà a #linea alla fine dell'URL e rendere il colore dello sfondo dell'intera linea come giallo. Questo è utile per indicare la linea esatta. Accetta anche intervalli di righe aggiungendo # Start-end. Ecco alcuni esempi di collegamento a linee e collegamenti a linee.
Strumento 8: documentazione
In questa sezione, esploreremo due metodi di documentazione:
Documentazione formale: Github Wiki per creare documentazione per il codice sorgente
Documentazione informale: Github Hubot per documentare le discussioni tra i membri del team e automatizzare il recupero delle informazioni interagendo con un divertente chat bot!
Menzioni, scorciatoie e Emoji
Github Wiki
Un Github Wiki può essere creato con ciascun repository e questo può essere estremamente utile per inserire sia il codice sorgente che la documentazione nello stesso repository. Per creare il Wiki, accedi alla scheda Wiki sull'intestazione principale e sei impostato per creare pagine con informazioni. Lo stesso Wiki ha il proprio controllo delle versioni ei dati possono essere clonati nel nostro computer locale per aggiornamenti o anche per l'accesso offline.
Una cosa che trovo molto utile è l'integrazione di Github Wiki nel progetto del codice sorgente principale in modo da non dover mantenere due progetti git separati. Per fare ciò, aggiungo il Wiki git repo come sottomodulo dal ramo principale. Se si utilizza Travis CI o qualsiasi altro CI, assicurarsi che lo strumento di costruzione ignori il sottomodulo wiki. Per il file di Travis CI .travis.yml, aggiungere il seguente:
git: submodules: false
Quindi aggiungi una wiki del sottomulo git al repository di codice principale:
$ git submodule add [email protected]: [username] / [repo-name] .wiki.git Clonazione in 'hello-team.wiki' ... remoto: conteggio oggetti: 6, fatto. remote: compressione di oggetti: 100% (3/3), fatto. remote: Total 6 (delta 0), riutilizzato 0 (delta 0) Oggetti di ricezione: 100% (6/6), fatto. $ git add. $ git commit -m "ha aggiunto wiki come sottomodulo" $ git push origin master
Ora il Wiki apparirà ordinatamente come sottomodulo all'interno del progetto del codice sorgente principale.
Github Hubot
Hubot, in breve, può enormemente aggiungere un sacco di divertimento nella documentazione e nella notifica delle discussioni di gruppo su importanti commit.
Hubot è semplicemente un bot di chat in grado di recuperare informazioni o fornire notifiche quando si è connessi a commit, problemi o attività di Github. In un team che cerca di ridurre significativamente le riunioni o addirittura di eliminarle completamente, Hubot con un'interfaccia di chat tra i membri del team aiuta a documentare ogni singola discussione. Certamente promuove tempi di lavoro flessibili, in quanto nessuno deve essere presente nello stesso momento per le discussioni. Avvertenza: Hubot è terribilmente coinvolgente!
Con questo, iniziamo con la configurazione di Hubot ospitato su Heroku e come bot con l'interfaccia di chat Campfire! Sia per Heroku che per Campfire, ci sono versioni gratuite per iniziare.
Useremo la versione di Hubot di Github's Campfire. Se lo desideri, puoi consultare gli adattatori per altre chat come Skype, IRC, Gtalk, ecc.
Apri un nuovo account Campfire solo per l'Hubot e questo account creerà una nuova chat room a cui tutti gli altri saranno invitati in seguito.
Distribuire Hubot su Heroku con le istruzioni fornite nel Wiki Hubot. Non allarmarti se l'ur di app heroku dà un Non può ottenere / in quanto non c'è nulla da ottenere di default.
Dall'account Hubot Campfire, invita te stesso. Ora, accedi al tuo account Campfire ed esegui Aiuto Hubot. Vi darà tutto il comando disponibile per hubot.
Provare, ad esempio hubot lo spedisce o hubot mi mappa CERN.
Successivamente, aggiungeremo uno script Hubot. Ce ne sono molte disponibili con illustrazioni di comando.
Ad esempio, aggiungeremo lo script github-commit in modo che ogni volta che c'è un commit, Hubot ci notificherà nella chat room. Metti il file github-commits.coffee dentro il script cartella.
Aggiornare package.json file con le dipendenze rilevanti come indicato su ciascun file di script hubot sotto i commenti.
Distribuire le modifiche a Heroku ancora una volta con git push heroku master.
Passare al repository nel Github di cui verrà visualizzata la notifica di commit nella chat. Aggiungi nel web hook sotto impostazioni repo. Nel caso del suddetto script "github-commit", il webhook sarà [HUBOT_URL]: [PORT] / hubot / gh-impegna camera = [ROOM_ID]?
La volta successiva che il repository ha un commit, Hubot chatterà e lo dirà!
Controlla altri script Hubot relativi a Github, o se vuoi scriverne uno c'è anche un fantastico tutorial su questo! Hubot, in breve, può enormemente aggiungere un sacco di divertimento nella documentazione e nella notifica delle discussioni di gruppo su importanti commit, problemi e attività che si svolgono con i nostri repository Github. Provaci!
Come nota finale sul lavoro con il team su Github, ecco alcuni suggerimenti sulla produttività:
menzioni - In qualsiasi area di testo, possiamo citare un altro utente github con @utente e l'utente riceverà una notifica del commento
Tasti di scelta rapida - stampa [cambio] + ? per accedere ai tasti di scelta rapida Github su qualsiasi pagina.
emoji - Usando il cheat Emoji, Github textareas supporta anche l'inserimento di icone. Vai avanti e divertiti con i tuoi compagni di squadra!
Collaborazione non software su Github
Molti di noi penseranno di usare Github solo per progetti software. Dopotutto, Github è stato avviato per la "codifica" sociale. Ma ci sono alcuni fantastici repository Github che vengono utilizzati per progetti non codificanti, ed erano ugualmente fantastici per la collaborazione e la discussione. Poiché questi progetti sono anche open source e chiunque può contribuire, è veloce correggere errori, segnalare bug ed è efficace collaborare con persone che la pensano allo stesso modo. Solo per divertimento, eccone alcuni:
Correzioni domestiche: Rileva il monitoraggio come strumento di monitoraggio
Libri: Little MongoDB Book, Backbone Fundamentals
Testi: JSConfEU testi
Trova fidanzato: boyfriend_require
mentoring: wiki
Dati genomici: Ash Dieback epidemia
Blog: Wizardry CSS
E chiedendosi cosa ne pensa il team Github a riguardo?
"Scaviamo divertiti usi di GitHub come questo"
Altre risorse
Social Coding in GitHub, un documento di ricerca della Carnegie Melon University
Share
Accentsconagua
