Colaborarea echipei cu GitHub

GitHub a devenit piatra de temelie pentru toate programele open source. Dezvoltatorii îl iubesc, colaborează și construiesc în mod constant proiecte minunate prin intermediul acestuia. În afară de găzduirea codului nostru, atracția principală a lui GitHub o folosește ca un instrument de colaborare. În acest tutorial, să explorăm unele dintre cele mai utile funcții GitHub, în special pentru a lucra în echipe, făcând-o tot mai eficientă, productivă și, cel mai important, distractivă!

Github și colaborarea software

Un lucru pe care îl consider foarte util este integrarea Github Wiki în proiectul cu cod sursă principal.

Acest tutorial presupune că sunteți deja familiarizat cu Git, sistemul de control al versiunii distribuite open source, creat de Linus Torvalds în 2005. Dacă aveți nevoie de o revizuire sau de o căutare în Git, vizitați cursul precedent sau chiar câteva postări. De asemenea, ar trebui să aveți deja un cont Github și ați făcut câteva funcții de bază, cum ar fi crearea unui depozit și împingerea modificărilor la Github. Dacă nu, treceți la mai multe tutoriale din trecut.

În lumea proiectelor software, este inevitabil să ne găsim într-o echipă care să realizeze un proiect. Pentru acest tutorial despre Github și colaborarea în echipă, vom explora unele dintre cele mai comune instrumente de care avem nevoie în general atunci când lucrăm cu echipe de software. Instrumentele discutate sunt:

Adăugarea membrilor echipei - Organizație și colaboratori
Trage Cereri - Trimitere & fuziune
Urmărirea bugurilor - Probleme Github
Google Analytics - Grafice și rețea
Management de proiect - Trello & Pivotal Tracker
Integrare continuă - Travis CI
Revizuire a Codului - Line Commenting & URL queries
documentarea - Wiki și Hubot

Preferați un scenariu?

Dacă preferați un screencast pentru o plimbare vizuală, treceți chiar mai jos pentru al vizualiza și consultați acest tutorial sub forma unor note:

Descărcați video

Instrumentul 1: Adăugarea membrilor echipei

În general, există două modalități de a crea Github pentru colaborarea în echipă:

organizaţii - Proprietarul organizației poate crea numeroase echipe cu diferite niveluri de permisiune pentru diferite depozite
colaboratori - Titularul depozitului poate adăuga colaboratori cu accesul Read + Write pentru un singur depozit

organizaţii

Dacă supravegheați mai multe echipe și doriți să setați diferite niveluri de permisiune pentru fiecare echipă cu diferiți membri și să adăugați fiecare membru în diferite depozite, organizația ar fi cea mai bună opțiune. Orice cont de utilizator Github poate crea deja organizații gratuite pentru depozite de cod open source. Pentru a crea o organizație, pur și simplu răsfoiți pagina de setări a organizației:

Pentru a accesa pagina de echipe pentru organizația dvs., puteți merge pur și simplu la http://github.com/organizations/[organization-name]/teams pentru a le vedea sau chiar a vizita https://github.com/organizations/[organization-name]/teams/new pentru a crea noi echipe cu membrii a 3 niveluri diferite de permisiune, cum ar fi:

Numai trageți: Fetch și Merge cu un alt depozit sau o copie locală. Citiți numai accesul.
Impinge si trage: (1) împreună cu actualizarea repo-ului la distanță. Citiți + Scriere acces.
Push, Pull & Administrative: (1), (2) împreună cu drepturile de facturare, crearea de echipe și anularea conturilor organizației. Citiți + Scriere + Acces administrare

colaboratori

Colaboratorii sunt obișnuiți să ofere ambele Citiți + Scriere acces la un singur depozit deținut de un cont personal. Pentru a adăuga colaboratori, (alte conturi personale Github) mergeți doar la https://github.com/[username]/[repo-name]/settings/collaboration:

Odată ce acest lucru va fi realizat, fiecare colaborator va vedea o modificare a stării de acces pe pagina de depozit. După ce avem accesul Scriere la depozit, putem face a git clone, lucrați la schimbări, faceți a git trageți pentru a prelua și a îmbina toate modificările în depozitul de la distanță și în cele din urmă git push, pentru a actualiza depozitul la distanță cu modificările proprii:

Instrumentul 2: trageți cererile

Cererile de tragere sunt o modalitate minunată de a contribui independent la un depozit prin forarea acestuia. La sfarsitul zilei, daca dorim, putem trimite o solicitare de tragere catre proprietarul depozitului pentru a ne fuziona schimbarile de cod. Cererea de tragere în sine poate declanșa dezbaterile privind calitatea codului, caracteristicile sau chiar strategia generală.

Să trecem acum la pașii de bază pentru o cerere de tragere.

Inițierea unei solicitări de tragere

Există două modele de solicitare de tragere în Github:

Fork & Pull Model - Folosit într-un depozit public pentru care nu avem acces push
Partajați modelul depozitului - Folosit într-un depozit privat pentru care avem un acces de tip push. Furcul nu este necesar în acest caz.

Aici vedem fluxul de lucru între doi utilizatori (repo-proprietar și bifurcată-repo-proprietar) pentru modelul Fork and Pull:

Identificați depozitul Github la care doriți să contribuiți și faceți clic pe butonul "Fork" pentru a crea o clonă a depozitului în contul dvs. Github:
Aceasta va crea o copie exactă a depozitului în contul dvs. propriu
Alegeți adresa URL SSH astfel încât să solicite expresia de acces cheie cheie SSH în locul numelui de utilizator și a parolei de fiecare dată când vă aflați git push sau git trageți. Apoi, vom clona acest depozit la mașina noastră locală:
```
 $ git clone [ssh-url] [nume-folder] $ cd [nume-folder]
```
În general, vom crea o nouă filială git pentru fiecare caracteristică nouă. Aceasta este o bună practică deoarece, în viitor, dacă vom actualiza ulterior sucursala după unele discuții, cererea de tragere va fi actualizată automat. Să creăm o nouă filială pentru a face o schimbare foarte simplă pentru a modifica readme.md fişier:
```
 $ git checkout -b [caracteristică nouă]
```
După efectuarea adăugărilor relevante pentru a construi noile caracteristici, noi vom angaja noile modificări și checkout în fabrica principală git:
```
 $ git add. $ git commit -m "informații adăugate în readme" $ git master checkout
```
În acest moment, vom împinge ramura în depozitul de la distanță. Pentru aceasta, vom verifica mai întâi numele filialei cu noua caracteristică, precum și alias-urile de depozitare la distanță de la Git. Apoi vom împinge modificările folosind git push [git-alias de la distanță] [branch-name]:
```
 $ git branch * master readme $ git la distanță -v origine [email protected]: [forked-repo-owner-username] / [repo-nume] .git (fetch) origine [email protected]: proprietar-nume de utilizator] / [repo-nume] .git (push) $ git push origine readme
```
În pagina noastră de depozitare cu furcă Github, vom trece la filiala cu noua funcție și apoi vom apăsa butonul "Trageți solicitarea".
După trimiterea solicitării de tragere, ne va duce direct la pagina de solicitare a tragerii originale a depozitului. Vom vedea solicitarea noastră de tragere, atât ca o problemă nouă, cât și ca o nouă solicitare de tragere.
După discuție, s-ar putea să fie posibil ca proprietarul repozitorului cu furcă să vrea să adauge modificări în noua funcție. În acest caz, vom verifica la aceeași ramură în mașina noastră locală, o vom comite și vom împinge înapoi la Github. Când vizităm pagina de solicitare de tragere a magaziei originale, aceasta va fi actualizată automat!

Îmbinarea unei solicitări de tragere

Dacă sunteți proprietarul original al depozitului, există două modalități de a îmbina o solicitare de tragere primită:

Îmbinându-se direct pe Github: Dacă mergem direct în Github, asigurați-vă că nu există conflicte și că este gata să fuzionați în ramura principală. Proprietarul inițial al repozitorului poate să apese pe butonul verde "Merge Pull Request" pentru a face acest lucru:
Mergând în mașinile noastre locale: În alte cazuri, pot exista conflicte de îmbinare, iar după ce faceți clic pe butonul "info", Github va avea instrucțiuni clare cu privire la modul în care putem fuziona sucursala în mașina noastră locală, trăgând modificările din filiera contribuitorului:

Există diferite modele de ramificare utilizate pentru versiuni în echipele de dezvoltare software. Iată două modele populare de flux de lucru git: (1) flux de lucru Github care are un model simplu de ramificare și utilizează cereri de tragere și (2) Gitflow care are o ramificare mai extinsă. Modelul care va fi ales în cele din urmă va varia în funcție de echipă, de proiect și de situație.

Instrumentul 3: urmărirea erorilor

Cererile de tragere sunt o modalitate minunată de a contribui independent la un depozit prin forarea acestuia.

În Github, centrul pentru toate urmăririle de erori sunt Problemele. Chiar dacă acestea sunt în primul rând pentru urmărirea erorilor, este de asemenea util să utilizați problemele în următoarele moduri:

Gandaci: Lucruri care sunt în mod evident rupte și necesită reparații
Caracteristici: Minunate idei minunate de pus în aplicare
Pentru a face lista: O listă de verificare a elementelor de completat

Să explorăm câteva dintre caracteristicile problemelor:

etichete: Sunt categorii colorate pentru fiecare problemă. Ele sunt utile pentru filtrarea problemelor în consecință.
Puncte de reper: Acestea sunt date din categorii care pot fi asociate cu fiecare problemă și sunt utile pentru a identifica ce probleme trebuie să fie lucrate pentru următoarea versiune. De asemenea, deoarece Milestone-urile sunt conectate la probleme, se actualizează automat bara de progres la închiderea fiecărei probleme asociate.
Căutare: Căutarea completă automată a ambelor probleme și a reperelor

Misiune: Fiecare problemă poate fi atribuită unei persoane responsabile pentru remedierea problemei. Este o altă trăsătură utilă pentru a vedea la ce ar trebui să lucrăm.

Auto-închidere: Trimiteți mesajele cu Remedieri / Fixe sau Închidere / Închidere / Închis # [număr de emitere] va închide automat problema.
```
 $ git add. $ git commit -m "corectat url. stabilește # 2" $ git push master de origine
```
mentiuni: Oricine poate lăsa de asemenea o notă doar indicând #[Număr de emitere] în mesajele lor. Deoarece numerele de problemă sunt hiperlinkate, acest lucru face foarte ușor să menționăm problemele legate de acestea în timpul discuțiilor.

Instrumentul 4: Google Analytics

Este clar că ne putem cupla strâns lista de sarcini și actualizările comitetelor noastre de cod.

Există două instrumente care oferă o perspectivă asupra unui depozit - Grafice și Rețea. Github Graphs oferă o perspectivă asupra colaboratorilor și se angajează în spatele fiecărui depozit de coduri, în timp ce Github Network furnizează o vizualizare a fiecărui colaborator și a angajamentelor sale în toate depozitele cu furcă. Aceste analize și grafice devin foarte puternice, mai ales atunci când lucrează în echipe.

Grafice

Graficele oferă analize detaliate, cum ar fi:

colaboratori: Cine au fost contribuabili? Și câte linii de cod au adăugat sau șterse?
Activitatea de angajare: În ce săptămâni au avut loc comitetele în ultimul an?
Frecvența codului: Câte linii de cod au fost comise pe parcursul întregului ciclu de viață al proiectului?
Punchcard: În care momente ale zilei au loc, de obicei, comitetele?

Reţea

Github Network este un instrument puternic care vă permite să vedeți comitetele fiecărui colaborator al fiecărui contribuitor și modul în care sunt legate una de cealaltă. Când ne uităm la vizualizator în întregime, vedem fiecare comitere pe fiecare ramură a fiecărui depozit care aparține unei rețele. Profund!

Instrumentul 5: Management de proiect

În timp ce problemele Github au capacități de gestionare a proiectelor cu probleme și repere, unele echipe ar putea prefera un alt instrument din cauza altor funcții sau a fluxului de lucru existent. În această secțiune, vom vedea cum putem lega Github cu alte două instrumente populare de gestionare a proiectelor - Trello și Pivotal Tracker. Cu ajutorul cârligelor de service Github, putem automatiza activitatea de actualizare cu comitete, probleme și multe alte activități. Această automatizare ajută nu numai la economisirea timpului, ci și la creșterea corectitudinii actualizărilor pentru orice echipă de dezvoltare software.

Github și Trello

Trello oferă un mod simplu, vizibil de gestionare a sarcinilor. Folosind metodologiile de dezvoltare a software-ului Agile, cardurile Trello pot emula un simplu board virtual Kanban. De exemplu, vom crea automat o cartelă Trello ori de câte ori o cerere de tragere este făcută folosind Github Service Hooks. Să trecem pe trepte!

Deschideți un cont în Trello dacă nu aveți deja unul și creați un nou Trello Board.
Accesați depozitul Github> Setări> Cârlige de serviciu> Trello
Obține JETON sub Instalați notele # 1 cu hyperlinkul furnizat pentru autentificare.
Sub Instalați notele # 2, utilizați adresa URL dată pentru a genera o structură JSON formatată care ne dă id de listă pentru fiecare carte Trello. BOARDID face parte din adresa URL atunci când vizităm comanda la https://trello.com/board/[BOARD-NAME]/[BOARDID]. JETON pot fi create cu hyperlink-ul dat în Install Notes # 1.
Înapoi în cârligele de serviciu Github, puneți în id de listă si jeton. Verificați Active, Test Cârlig și suntem toți pregătiți să obținem actualizări automate de fiecare dată când există o solicitare de tragere.
Data viitoare când există o solicitare de tragere, cardul Trello de cerere de tragere va avea în mod automat un element nou!

Github și Pivotal Tracker

Pivotal Tracker este un alt instrument ușor de gestionat pentru proiecte agile, unde planificarea bazată pe povesti permite echipei să colaboreze cu ușurință, reacționând instantaneu la diverse schimbări și progrese ale proiectului. Pe baza evoluției actuale a echipei, aceasta poate crea și diagrame pentru a analiza viteza echipei, arderea iterației, arderea lansărilor etc. În acest scurt exemplu, vom difuza în mod automat o poveste prin legarea acesteia la o comisie Github!

Creați un nou proiect în Pivotal Tracker cu un nou Story care trebuie livrat.
Accesați Profile> API Token (chiar în partea de jos). Copiați tokenul API oferit.
Reveniți la depozitul Github> Setări> Cârlige de service> Pivotal Tracker. Inserați jetonul, bifați Active și faceți clic pe Actualizare setări. Suntem cu toții pregătiți să livrăm în mod automat știri Pivotal Tracker cu comitetele Github!
În cele din urmă, ne vom angaja modificările și vom adăuga ID tracker la mesajul de comitet cu formatul git commit -m "mesaj [livrează #tracker_id]"
```
 $ git add. $ git commit -m "Cârligele Github și Pivotal Tracker implementate [livrează # 43903595]" $ git push
```
Acum, când ne întoarcem la Pivotal Tracker, vom vedea că povestea a fost livrată automat cu link-uri către comanda exactă Github care arată modificările fișierelor!

Cu aceste exemple Trello și Pivotal Tracker, este clar că ne putem cupla strâns lista de sarcini și actualizările comenzilor noastre de cod. Acesta este un imens timp de economisire atunci când lucrează într-o echipă, și îmbunătățește acuratețea atunci când se leagă sarcini de comiterea exactă. Vestea bună este că, dacă utilizați deja alte instrumente de gestionare a proiectelor, cum ar fi Asana, Basecamp și altele, puteți crea și cârlige de service într-un mod similar. Dacă nu există cârlige de service existente pentru instrumentul actual de gestionare a proiectelor, puteți crea chiar unul!

Instrumentul 6: Integrare continuă

Integrarea continuă (CI) este o parte importantă a tuturor proiectelor de dezvoltare software care lucrează cu echipe. CI asigură că, atunci când un dezvoltator verifică în codul lor, o construcție automată (inclusiv teste) detectează erorile de integrare cât mai repede posibil. Acest lucru reduce cu siguranță erorile de integrare și face repetarea rapidă mult mai eficientă. În acest exemplu, vom vedea cum poate fi folosit Travis CI cu Github pentru CI pentru a detecta erorile, precum și pentru a recomanda îmbinarea atunci când trece toate testele.

Configurarea Travis CI

Vom folosi un simplu proiect "hello-world" pentru node.js cu grunt.js ca instrument de construire pentru a configura un proiect Travis CI. Iată fișierele din proiect:

hello.js fișierul este proiectul nodului. Aici vom lăsa în mod intenționat un punct și virgulă astfel încât să nu treacă instrumentul de construire a gruntului pentru a linge:

 var http = necesită ("http"); http.createServer (funcția (req, res) res.writeHead (200, 'Content-Type': 'text / plain');) res.end ('Hello World in Node! \ n') // fără punct și virgulă , aceasta nu va trece linting). asculta (1337, '127.0.0.1'); console.log ("Serverul rulează la http://127.0.0.1:1337/");

package.json denotă dependențele:

 name: "hello-team", "description": "Un demo pentru github și travis ci pentru colaborarea în echipă", "author": "name "," versiunea ":" 0.0.1 "," devDependencies ": " grunt ":" ~ 0.3.17 "," scripts ": " test ":" grunt travis --verbose "

gruntjs instrumentul de construire are doar o singură sarcină (linging) doar pentru simplitate:

 modul.exports = funcție (grunt) grunt.initConfig (lint: fișiere: ['hello.js']); grunt.registerTask ("implicit", "lint"); grunt.registerTask ("travis", "lint"); ;

.travis.yml este un fișier de configurare Travis care va face Travis să ruleze testele noastre:
```
 limbă: node_js node_js: - 0.8
```
Apoi, conectați-vă la Travis cu contul dvs. Github și activați cârligul de depozitare sub fila depozitului.
Dacă pasul anterior nu declanșează construirea, atunci va trebui să configurați manual cârligul de serviciu. Pentru a o seta manual, copiați Tokenul sub fila profil.
Întoarceți-vă la magazia Github pentru a configura carligele de service Github Travis cu jetonul.
Pentru prima dată, trebuie să facem un manual git push pentru a declanșa construirea primului Travis și dacă totul este în regulă, vizitați http://travis-ci.org/[username]/[repo-name] pentru a vedea starea de construire ca trecere!

Travis CI cu solicitări de tragere

Anterior, fără CI în procesul de solicitare de tragere, pașii au mers așa ceva (1) au trimis testul de solicitare (2) fuzionare (3) pentru a vedea dacă trece / eșuează. Cu Travis CI cuplat cu cererile de tragere, vom putea inversa pașii 2 și 3, sporind tot mai rapid luarea deciziilor cu privire la faptul dacă este sau nu bine să fuzăm cu Travis, oferindu-ne statutul cu fiecare solicitare de tragere. Să vedem cum să se întâmple asta.

Trimiteți o cerere de tragere cu o construcție trecătoare și Travis își va face magia pentru a vă anunța că este bine să fuzionați chiar înainte de a fuziona
Dacă Solicitarea de tragere nu reușește construirea, Travis vă va avertiza de asemenea.
Dacă faceți clic pe butonul roșu de avertizare, acesta va face legătura și cu pagina travis pentru a ne arăta detaliile construcției.

Travis CI cu Github este extrem de util pentru echipe datorită construirii automate și notificării imediate. Cu siguranță, ciclul de corectare a erorilor este mult mai scurt. Dacă utilizați Jenkins, un alt instrument popular CI, da, puteți configura și cârligele de service Github în mod similar.

Instrumentul 7: Revizuirea codului

Cu fiecare angajament, Github permite o interfață curată pentru comentarii generale sau chiar pentru comentarii specifice pe o linie de cod. Abilitatea de a ridica comentarii sau întrebări pe fiecare linie de cod este foarte utilă în a face linii de comentarii de coduri de linie. Pentru a vizualiza comentariile inline, comutați comanda on-off de pe caseta de selectare din dreptul fiecărei comitete.

Să explorăm câteva modele de adrese URL care pot fi folosite pentru a ne ajuta să examinăm codul, oferindu-ne rapid diferențele dintre comitete:

Comparați sucursalele / etichetele / SHA1 : utilizați modelul de adresă URL https://github.com/[username]/[repo-name]/compare/[starting-SHA1]... [ending-SHA1]. Puteți face același lucru cu ramura sau etichetele.
Comparați fără spațiu alb : adăuga ?w = 1 la urlurile de comparare
dif : adăuga .dif pentru a compara adresele URL pentru a obține git diff informații în text simplu. Acest lucru ar putea fi util în scopuri de scripting.
Plasture : adăuga .plasture pentru a compara adresele URL pentru a obține git diff informații formatate pentru trimiterile de e-mail pentru patch-uri.
Linia de legătură : Când facem clic pe numărul de linie din orice fișier, Github va adăuga a #linia la sfârșitul adresei URL și a face ca întreaga linie de fundal să fie galbenă. Acest lucru este bine pentru a arăta linia exactă. De asemenea, acceptă intervalele de linie prin adăugarea # Start-end. Iată câteva exemple de legare a liniei și de legare la nivel de linie.

Instrumentul 8: Documentarea

În această secțiune, vom explora două metode de documentare:

Documentație formală: Github Wiki pentru a crea documentația pentru codul sursă
Informație neoficială: Github Hubot pentru a documenta discuțiile între membrii echipei și pentru a automatiza regăsirea informațiilor prin interacțiunea cu un bot de chat distractiv!
Mențiuni, Comenzi rapide și Emoji

Github Wiki

Un Github Wiki poate fi creat cu fiecare depozit, iar acest lucru poate fi extrem de util pentru a pune ambele coduri sursă și documentația în același depozit. Pentru a crea Wiki, trebuie doar să accesați fila Wiki din antetul principal și să setați să creați pagini cu informații. Wiki în sine are propria versiune, iar datele pot fi clonate în mașina noastră locală pentru actualizări sau chiar acces offline.

Un lucru pe care îl consider foarte util este integrarea Github Wiki în proiectul principal al codului sursă, astfel încât să nu trebuiască să mențin două proiecte separate GIT. Pentru a face acest lucru, adaug Wiki git repo ca un submodul din ramura master. Dacă utilizați Travis CI sau orice alt CI, asigurați-vă că instrumentul de construcție ignoră submodulul wiki. Pentru fișierul Travis CI .travis.yml, adăugați următoarele:

 git: submodule: false

Apoi adăugați un wit submodul git la depozitul de coduri principale:

 $ git submodule adăugați [email protected]: [username] / [repo-name] .wiki.git Clonarea în 'hello-team.wiki' ... remote: Numărarea obiectelor: 6, terminat. la distanță: comprimarea obiectelor: 100% (3/3), terminat. la distanță: Total 6 (delta 0), refolosit 0 (delta 0) Obiectele primite: 100% (6/6), terminat. $ git add. $ git commit -m "wiki adăugat ca submodul" $ git push master de origine

În prezent, Wiki va apărea ca un submodul în cadrul proiectului principal de cod sursă.

Github Hubot

Hubot, pe scurt, poate adăuga extraordinar de multă distracție în documentarea și notificarea discuțiilor de echipă cu privire la comitete importante.

Hubot este pur și simplu un bot de chat care poate prelua informații sau poate oferi notificări atunci când este conectat la comitete, probleme sau activități Github. Într-o echipă care încearcă să reducă în mod semnificativ întâlnirile sau chiar să le elimine total, Hubot, cu o interfață de chat între membrii echipei, ajută la documentarea fiecărei discuții. Cu siguranță promovează o perioadă de lucru flexibilă, deoarece nimeni nu trebuie să fie prezent în același timp pentru a avea loc discuții. Avertisment: Hubot este extrem de dependență!

Cu aceasta, să începem cu instalarea lui Hubot găzduit pe Heroku și ca un bot cu interfața de chat Campfire! Atât pentru Heroku cât și pentru Campfire, există versiuni gratuite pentru a începe.

Vom folosi versiunea Github's Campfire a lui Hubot. Dacă doriți, puteți verifica adaptoarele pentru alte chat-uri, cum ar fi Skype, IRC, Gtalk etc..
Deschideți un nou cont Campfire doar pentru Hubot și acest cont va crea o nouă cameră de chat pe care toți ceilalți vor fi invitați mai târziu.
Deplasați Hubot la Heroku cu instrucțiunile date în Wiki-ul Hubot. Nu fi alarmat dacă adresa URL a aplicației heroku dă un mesaj Nu se poate obține / deoarece nu există nimic de obținut în mod implicit.
Din contul Hubot Campfire, invitați-vă. Acum, intrați în contul Campfire și executați Ajutor Hubot. Va va da toate comenzile disponibile pentru hubot.
Încercați, cum ar fi hubot-l navă sau hubot harta mea CERN.
Apoi, vom adăuga un script Hubot. Există o mulțime disponibilă cu ilustrații de comandă.
De exemplu, vom adăuga scriptul github-commit, astfel încât, de fiecare dată când există comiterea, Hubot ne va anunța în camera de chat. Puneți fișierul github-commits.coffee în interiorul script-uri pliant.
Actualizați package.json fișier cu dependențele relevante, așa cum este instruit în partea de sus a fiecărui fișier script hubot sub comentarii.
Implementați din nou modificările la Heroku git push master heroku.
Navigați la magazia din Github a cărei notificare de comitet va fi afișată în chat. Adăugați cârligul web sub setările repo. În cazul scriptului "github-commit", găzduirea va fi [HUBOT_URL]: [PORT] / hubot / gh-comite o cameră = [ROOM_ID]?
Data viitoare când depozitul are un comitet, Hubot va vorbi și va spune!

Verificați alte scripturi Hubot legate de Github, sau dacă doriți să scrieți, există un tutorial minunat și pentru asta! Hubot, pe scurt, poate adăuga foarte mult distracție în documentarea și notificarea discuțiilor în echipă cu privire la comitetele, problemele și activitățile importante care au loc cu depozitele noastre Github. Incearca!

Ca o notă finală privind colaborarea cu echipa pe Github, iată câteva sfaturi despre productivitate:

menţionează - În orice zonă de text, putem menționa un alt utilizator github cu @utilizator iar utilizatorul va primi notificarea comentariului
Taste rapide - presa [schimb] + ? pentru a accesa cheile de comenzi rapide Github pe orice pagină.
Emoji - Folosind foaia de înșelătorie Emoji, Github textareas acceptă, de asemenea, inserarea de pictograme. Du-te și distrează-te cu colegii tăi de echipă!

Colaborare non-software pe Github

Majoritatea dintre noi ne vom gândi să folosim Github numai pentru proiectele software. La urma urmei, Github a fost demarat pentru "codificare" socială. Dar, există câteva depozite Github cool care sunt folosite pentru proiecte non-codare și au fost la fel de minunate pentru colaborare și discuții. Deoarece aceste proiecte sunt, de asemenea, open source și oricine poate contribui, este rapid pentru a repara erorile, pentru a raporta cu ușurință bug-uri și pentru a colabora eficient cu oameni asemănători. Doar pentru distracție, iată câteva dintre ele:

Repararea acasă: Emiterea urmăririi ca instrument de monitorizare
Cărți: Little Book MongoDB, fundamentele fundamentale
Versuri: Versuri JSConfEU
Găsește-ți prietenul: boyfriend_require
Mentoring: Wiki
Date genomice: Epidemia de coșmar
Blog-uri: CSS Wizardry

Și întrebam ce gândește echipa Github?

"Folosim utilizările distractive ale lui GitHub ca acesta"

Mai multe resurse

Codificarea socială în GitHub, o lucrare de cercetare a Universității Carnegie Melon
Cum Github folosește Github pentru a construi Github de Zac Holman
Git și Github

Cod