GitHub er blitt hjørnestenen for alle ting åpen programvare. Utviklere elsker det, samarbeider på det og bygger hele tiden fantastiske prosjekter gjennom det. Bortsett fra hosting vår kode, bruker GitHubs hovedattraksjon det som et samarbeidsverktøy. I denne opplæringen kan vi utforske noen av de mest nyttige GitHub-funksjonene, spesielt for å jobbe i lag, noe som gjør det mer effektivt, produktivt og viktigst morsomt.!
Github og Software Collaboration
En ting som jeg synes er veldig nyttig, er å integrere Github Wiki i hovedkildekodeprosjektet.
Denne opplæringen tar utgangspunkt i at du allerede er kjent med Git, styringssystemet for åpen kildekode distribuert versjon, opprettet av Linus Torvalds i 2005. Hvis du trenger en revisjon eller en oppslag på Git, kan du besøke vårt forrige screencast-kurs eller til og med noen innlegg. Også, du bør allerede ha en Github-konto og gjorde noen grunnleggende funksjoner, for eksempel å opprette et lager og skyve endringer til Github. Hvis ikke, gå over til flere tidligere opplæringsprogrammer på det.
I programvareprosjektets verden er det uunngåelig at vi finner oss selv i et team for å levere et prosjekt. For denne opplæringen om Github og team samarbeid, vil vi undersøke noen av de vanligste verktøyene som vi vanligvis trenger når vi jobber med programvarelag. De diskuterte verktøyene er:
Legge til lagmedlemmer - Organisasjon og samarbeidspartnere
Trekkforespørsler - Sende og slå sammen
Feilsøking - Github Issues
Analytics - Grafer og nettverk
Prosjektledelse - Trello & Pivotal Tracker
Kontinuerlig integrering - Travis CI
Kode anmeldelse - Linjebeskrivelse og URL-spørringer
dokumentere - Wiki og Hubot
Foretrekker en Screencast?
Hvis du foretrekker en screencast for en visuell gjennomgang, hopper du bare ned for å se den og refererer til denne opplæringen som sidenotater:
Last ned video
Verktøy 1: Legge til lagmedlemmer
Det er generelt to måter å sette opp Github for teamsamarbeid:
organisasjoner - Organisasjonseier kan opprette mange lag med ulike tillatelsesnivåer for ulike repositorier
samarbeidspartnere - Repository eier kan legge til samarbeidspartnere med Read + Skriv tilgang for et enkelt lager
organisasjoner
Hvis du overvåker flere lag og ønsker å sette forskjellige tillatelsesnivåer for hvert lag med ulike medlemmer og legge til hvert medlem til forskjellige repositorier, vil Organisasjonen være det beste alternativet. Enhver Github-brukerkonto kan allerede opprette gratis organisasjoner for åpen kildekode-repositories. Hvis du vil opprette en organisasjon, kan du bare bla til organisasjonens innstillingsside:
For å få tilgang til lagssiden for organisasjonen din, kan du bare gå til http://github.com/organizations/[organization-name]/teams å se dem eller besøke https://github.com/organizations/[organization-name]/teams/new å skape nye lag med medlemmer av 3 forskjellige tillatelsesnivåer som:
Trekk bare: Hent og slå sammen med et annet depot eller en lokal kopi. Les kun tilgang.
Dytte og dra: (1) sammen med oppdatering av ekstern repo. Les + Skriv tilgang.
Push, Pull & Administrative: (1), (2) sammen med rettigheter til faktureringsinformasjon, opprette lag samt kansellere organisasjonskontoer. Les + Skriv + Admin tilgang
samarbeidspartnere
Samarbeidspartnere er vant til å gi begge Les + Skriv tilgang til et enkelt lager som eies av en personlig konto. For å legge til Samarbeidspartnere, (andre Github personlige kontoer) bare gå til https://github.com/[username]/[repo-name]/settings/collaboration:
Når det er gjort, vil hver samarbeidspartner se en endring i tilgangsstatusen på lagringssiden. Etter at vi har skrive tilgang til depotet, kan vi gjøre en git klon, arbeid på endringene, gjør a git pull å hente og slå sammen eventuelle endringer i fjernregisteret og til slutt git push, å oppdatere fjernregisteret med egne endringer:
Verktøy 2: Trekkforespørsler
Pull-forespørsler er en fantastisk måte å bidra til et lagringssted uavhengig av forking det. På slutten av dagen, kan vi, hvis vi ønsker det, sende en trekkforespørsel til repositoryeieren for å slå sammen kodendringene våre. Trekkforespørselen i seg selv kan så avfalle diskusjoner for kodekvalitet, funksjoner eller til og med generell strategi.
La oss nå gå gjennom de grunnleggende trinnene for en trekkforespørsel.
Starte en trekkforespørsel
Det er to modeller for trekkforespørsel i Github:
Gaffel og trekkmodell - Brukes i et offentligt lager som vi ikke har push-tilgang til
Del Repository Model - Brukes i et privat lager som vi har push-tilgang til. Gaffel er ikke nødvendig, er dette tilfellet.
Her ser vi arbeidsflyten mellom to brukere (repo-eier og gaffel-repo-eier) for gaffel- og trekkmodellen:
Identifiser Github Repository som du vil bidra med, og klikk på "Gaffel" -knappen for å lage en klon av depotet i din egen Github-konto:
Dette vil skape en eksakt kopi av depotet på egen brukerkonto
Velg SSH-nettadressen slik at den vil be om SSH-nøkkelpassordet ditt i stedet for brukernavnet og passordet hver gang du git push eller git pull. Deretter vil vi klone dette depotet til vår lokale maskin:
$ git klon [ssh-url] [mappenavn] $ cd [mappenavn]
Generelt vil vi opprette en ny git-grenen for hver ny funksjon. Dette er en god praksis fordi i fremtiden hvis vi videre oppdaterer avdelingen etter noen diskusjoner, vil trekkforespørselen automatisk bli oppdatert. La oss lage en ny grenen for å gjøre en veldig enkel endring for å endre readme.md fil:
$ git checkout -b [ny funksjon]
Etter å ha gjort de relevante tilleggene til å bygge de nye funksjonene, vil vi bare forplikte de nye endringene og kassen til git master-grenen:
$ git add. $ git commit -m "informasjon lagt til i readme" $ git checkout master
På dette punktet skyver vi avdelingen til fjernregisteret. For dette vil vi først sjekke avdelingsnavnet med den nye funksjonen, samt git-fjernregisteraliasene. Da vil vi presse endringene med git push [git-remote-alias] [filnavn]:
I vårt forked-depot Github-siden vil vi bytte til grenen med den nye funksjonen og deretter trykke på "Pull Request" -knappen.
Etter at du har sendt inn forespørselen, vil den ta oss direkte til det originale arkivets forespørselsside. Vi vil se vår trekkforespørsel, både som et nytt problem, samt en ny trekkforespørsel.
Etter diskusjonen kan det være mulig at forked-depotets eier kanskje vil legge til endringer i den nye funksjonen. I dette tilfellet vil vi sjekke ut til samme avdeling i vår lokale maskin, forplikte den og trykke den tilbake til Github. Når vi besøker trekkforespørselssiden til det opprinnelige arkivet, blir det automatisk oppdatert!
Slå sammen en trekkforespørsel
Hvis du er den opprinnelige repositoryeieren, er det to måter å slå sammen en innkommende trekkforespørsel:
Fusjonere direkte på Github: Hvis vi fusjonerer direkte i Github, så sørg for at det ikke er konflikter, og det er klart å bli slått sammen i hovedgrenen. Det opprinnelige lagerets eier kan ganske enkelt klikke på grønnknappen "Merge Pull Request" for å gjøre det:
Slå sammen i våre lokale maskiner: På andre tidspunkter kan det fusjonere konflikter, og ved å klikke på "info" -knappen, vil Github ha klare instruksjoner om hvordan vi kan slå sammen grenen i vår lokale maskin ved å trekke inn endringene fra bidragsyterens gren:
Det finnes forskjellige forgreningsmodeller som brukes til versjonering i programvareutviklingsgrupper. Her er to populære git-arbeidsflytmodeller: (1) Github-arbeidsflyt som har en enkel forgreningsmodell og bruker trekkforespørsler og (2) Gitflow som har en mer omfattende forgrening. Modellen som til slutt blir valgt, vil definitivt variere avhengig av lag, prosjekt og situasjon.
Verktøy 3: Feilsøking
Pull-forespørsler er en fantastisk måte å bidra til et lagringssted uavhengig av forking det.
I Github er senteret for all bugsporing problemene. Selv om de primært er for feilsporing, er det også nyttig å bruke problemer på følgende måter:
bugs: Ting som er åpenbart brutt og må fikse
Egenskaper: Utrolig kule nye ideer å implementere
Gjøremålsliste: En sjekkliste over elementer som skal fullføres
La oss utforske noen av funksjonene i problemene:
etiketter: De er fargede kategorier for hvert problem. De er nyttige for å filtrere problemer tilsvarende.
milepæler: De er daterte kategorier som kan knyttes til hvert problem, og er nyttige for å identifisere hvilke problemer som skal arbeides for neste utgave. Siden milepæler er knyttet til problemer, oppdateres det automatisk fremdriftslinjen når du lukker hvert tilknyttet problem.
Søke: Automatisk fullfør søk etter både problemer og milepæler
Oppdrag: Hvert problem kan tildeles en person som er ansvarlig for å fikse problemet. Det er en annen nyttig funksjon for å se hva vi skal jobbe med.
Auto-close: Forbind meldinger med Fixes / Fixed eller Close / Closes / Closed # [issue-number] lukker problemet automatisk.
nevner: Alle kan også legge igjen et notat ved å bare indikere # [Problemet-nummer] i sine meldinger. Fordi nummerene er hyperkoblet, gjør dette det veldig enkelt å nevne relaterte problemer under diskusjon.
Verktøy 4: Analytics
Det er klart at vi kan tette sammen vår oppgaveliste og oppdateringer til våre kodeforpliktelser.
Det er to verktøy som gir innsikt i et lager - Grafer og nettverk. Github Graphs gir et innblikk i samarbeidspartnerne og forplikter seg bak hvert kodelager, mens Github Network gir en visualisering på hver bidragsytere og deres forpliktelser på tvers av alle forked-repositorier. Disse analysene og grafer blir svært kraftige, spesielt når du arbeider i lag.
grafer
Grafer gir detaljert analyse slik som:
bidragsytere: Hvem var bidragsyterne? Og hvor mange linjer med kode lagde de til eller slette?
Forlovelsesaktivitet: Hvilke uker har begåttene foregått i det siste året?
Kodefrekvens: Hvor mange linjer med kode ble begått gjennom hele prosjektets livssyklus?
Stemplingskort: Under hvilke tider pågår det vanligvis begivenheter?
Network
Github Network er et kraftig verktøy som lar deg se hver enkelt bidragsyters forpliktelser og hvordan de er relatert til hverandre. Når vi ser på visualiseringen i sin helhet, ser vi alle forpliktelser på hver gren i hvert depot som tilhører et nettverk. Innsiktsfull!
Verktøy 5: Prosjektledelse
Mens Github-problemer har prosjektstyringsfunksjoner med problemer og milepæler, kan noen lag foretrekke et annet verktøy på grunn av andre funksjoner eller eksisterende arbeidsflyt. I denne delen vil vi se hvordan vi kan koble Github med to andre populære prosjektstyringsverktøy - Trello og Pivotal Tracker. Med Github service kroker, kan vi automatisere oppdateringsoppgave med forpliktelser, problemer og mange andre aktiviteter. Denne automatiseringen hjelper ikke bare med å spare tid, men øker også nøyaktigheten i oppdateringer for ethvert programvareutviklingslag.
Github og Trello
Trello gir en enkel, visuell måte å administrere oppgaver på. Ved hjelp av Agile Software Development-metoder kan Trello-kort etterligne en enkel virtuell Kanban-styret. Som et eksempel, vil vi automatisk lage et Trello-kort når en Pull-forespørsel er laget ved hjelp av Github Service Hooks. La oss gå gjennom trinnene!
Åpne en konto i Trello hvis du ikke allerede har en og opprett et nytt Trello-styre.
Gå til Github-depotet> Innstillinger> Service kroker> Trello
Hent TOKEN under Installer Notes # 1 med hyperkoblingen som er oppgitt for godkjenning.
Under Installer Notater # 2, bruk nettadressen som er gitt til å generere en json-formatert struktur som gir oss liste id for hvert Trello-kort. BOARDID er en del av nettadressen når vi besøker styret på https://trello.com/board/[BOARD-NAME]/[BOARDID]. TOKEN kan opprettes med hyperkoblingen gitt under Installasjonsnotater # 1.
Tilbake i Github service kroker, sett inn liste id og pollett. Sjekk Active, Test Hook og vi er alle satt for å få automatiske oppdateringer hver gang det er en Pull Request.
Neste gang det er en Pull-forespørsel, vil Trull-kort-kortet automatisk få et nytt element!
Github og Pivotal Tracker
Pivotal Tracker er et annet lettvektsløst prosjektstyringsverktøy der historisk-basert planlegging gjør at teamet enkelt kan samarbeide ved å umiddelbart reagere på ulike endringer og fremdrift av prosjektet. Basert på lagets nåværende fremgang, kan det også lage diagrammer for å analysere teamet hastighet, gjentakelse brenne opp, slipper brenne ned, etc. I denne korte eksempel vil vi automatisk levere en historie ved å koble den til en Github begå!
Opprett et nytt prosjekt i Pivotal Tracker med en ny historie som må leveres.
Gå til Profil> API Token (rett nederst). Kopier API-token gitt.
Kom tilbake til Github-depotet> Innstillinger> Tjenestekroker> Pivotal Tracker. Lim inn symbolet, merk av Aktiv og klikk Oppdater innstillinger. Vi er alle satt til å automatisk levere Pivotal Tracker Stories med Github Commits!
Endelig vil vi forplikte våre endringer og legge til tracker-id til commit-meldingen med formatet git commit -m "melding [leverer #tracker_id]"
Nå, når vi kommer tilbake til Pivotal Tracker, vil vi se at historien har blitt automatisk levert med koblinger til det eksakte Github-commitet som viser filendringene!
Med disse Trello- og Pivotal Tracker-eksemplene er det klart at vi kan tette sammen vår oppgaveliste og oppdateringer til våre kodeforpliktelser. Dette er en enorm tidsbesparende når du arbeider i et lag, og det forbedrer nøyaktigheten når du kobler oppgaver til det nøyaktige forpliktelsen. Den gode nyheten er at hvis du allerede bruker andre prosjektstyringsverktøy som Asana, Basecamp og andre, kan du også opprette Service Hooks på samme måte. Hvis det ikke finnes noen eksisterende servicekroker for ditt nåværende prosjektstyringsverktøy, kan du til og med opprette en!
Verktøy 6: Kontinuerlig integrering
Kontinuerlig integrasjon (CI) er en viktig del av alle programvareutviklingsprosjekter som arbeider med lag. CI sikrer at når en utvikler sjekker i koden, oppdager en automatisert bygge (inkludert tester) integrasjonsfeil så fort som mulig. Dette reduserer integrasjonsfeilene definitivt og gjør det raskere å gjøre det raskere. I dette eksemplet vil vi se hvordan Travis CI kan brukes med Github for CI for å oppdage feil, samt anbefale sammenføyning når den overgår alle tester.
Sette opp Travis CI
Vi vil bruke et enkelt "hallo-verden" -prosjekt for node.js med grunt.js som byggverktøy for å sette opp et Travis CI-prosjekt. Her er filene i prosjektet:
De hello.js filen er nodeprosjektet. Her vil vi med hensikt legge ut et semikolon slik at det ikke vil passere grunt byggverktøy for linting:
var http = krever ('http'); http.createServer (funksjon (req, res) res.writeHead (200, 'Content-Type': 'text / plain'); res.end ( '! Hei verden i Node \ n') // uten semikolon , dette vil ikke passere linting). lytt (1337, '127.0.0.1'); console.log ('Server kjører på http://127.0.0.1:1337/');
package.json angir avhengighetene:
"navn": "hello-team", "description": "En demo for github og travis ci for team samarbeid", "forfatter": "navn ", "Versjon": "0.0.1", "devDependencies": "grynt": "~ 0.3.17", "skript": "test": "grunt travis verbose"
De gruntjs byggeverktøy har bare en oppgave (linting) bare for enkelhet:
.travis.yml er en Travis konfigurasjonsfil som gjør at Travis kjører testene våre:
språk: node_js node_js: - 0.8
Deretter logger du deg på Travis med Github-kontoen din og slår på lagerkroken under arkivarkivet.
Hvis trinnet før ikke utløser byggingen, må vi manuelt opprette servicekroken. For å sette opp manuelt, kopier du Token under profilfanen.
Gå tilbake til Github-depotet for å konfigurere Github Travis-servicekrokene med token.
For første gang må vi gjøre en håndbok git push å utløse den første Travis-bygningen, og hvis alt er i orden, bare besøk http://travis-ci.org/[username]/[repo-name] for å se byggestatus som bestått!
Travis CI med trekkforespørsler
Tidligere, uten CI i prosessen med en trekkforespørsel, gikk trinnene slik som denne (1) sendte trekkforespørsel (2) fusjonere (3) test for å se om den går / mislykkes. Med Travis CI hekta på trekkforespørsler, vil vi kunne reversere trinn 2 og 3, noe som øker rask beslutningstaking om hvorvidt det er bra å slå sammen med Travis, noe som gir oss statusen med hver trekkforespørsel. La oss se hvordan du får det til å skje.
Send en trekkforespørsel med en forbipasserende bygge, og Travis vil gjøre sin magi for å fortelle deg at det er godt å slå sammen selv før sammenslåing
Hvis trekkforespørselen mislykkes, vil Travis også varsle deg.
Hvis vi klikker på den røde varselknappen, vil den også lenke til travis siden for å vise oss detaljene til bygningen.
Travis CI med Github er utrolig nyttig for lag på grunn av automatiserte bygg og umiddelbar varsel. Det gjør absolutt feilkorreksjons syklusen mye kortere. Hvis du bruker Jenkins, et annet populært CI-verktøy, ja, du kan sette opp Github servicehooks på samme måte også.
Verktøy 7: Kode gjennomgang
Med hvert forpliktelse gir Github et rent grensesnitt for generelle kommentarer eller til og med spesifikke kommentarer på en linje med kode. Evnen til å hente kommentarer eller spørsmål på hver enkelt linje med kode er svært nyttig når du gjør linje etter linjekode anmeldelser. For å se kommentarene i inline, slår du av i avmerkingsboksen rett øverst på hvert commit.
La oss undersøke noen nettadressemønstre som kan brukes til å hjelpe oss med kodevurdering, ved å raskt gi oss forskjellene mellom forpliktelser:
Sammenlign grener / koder / SHA1 : Bruk URL-mønsteret https://github.com/[username]/[repo-name]/compare/[starting-SHA1]... [ending-SHA1]. Du kan gjøre det samme med filial eller tagger.
Sammenlign uten hvitt plass : Legg til ?w = 1 til sammenligningsadressene
diff : Legg til .diff til sammenligne nettadressene for å få tak i git diff informasjon i vanlig tekst. Dette kan være nyttig for skriptformål.
Lapp : Legg til .lapp til sammenligne nettadressene for å få tak i git diff informasjon formatert for e-postoppdateringer.
Linjelinking : Når vi klikker på linjenummeret på en fil, vil Github legge til en #linje på slutten av nettadressen og gjør hele linjens bakgrunnsfarge så gul. Dette er pent for å peke ut den eksakte linjen. Den aksepterer også linjene ved å legge til # Start-end. Her er eksempler på linjelink og linjeplasskobling.
Verktøy 8: Dokumentasjon
I denne delen vil vi utforske to dokumentasjonsmetoder:
Formell dokumentasjon: Github Wiki for å lage dokumentasjon for kildekoden
Uformell dokumentasjon: Github Hubot å dokumentere diskusjoner mellom lagmedlemmer og automatisere informasjonssøking ved å samhandle med en morsom chat bot!
Mentjoner, snarveier og emoji
Github Wiki
En Github Wiki kan opprettes med hvert lagringssted, og dette kan være svært nyttig å sette både kildekoden og dokumentasjonen under samme lagringsplass. Hvis du vil opprette Wiki, får du tilgang til Wiki-fanen på hovedoverskriften, og du er innstilt for å lage sider med informasjon. Wiki selv har sin egen versjon, og dataene kan klones inn i vår lokale maskin for oppdateringer eller til og med offline tilgang.
En ting som jeg synes er veldig nyttig, er å integrere Github Wiki i hovedkildekodeprosjektet, slik at jeg ikke behøver å opprettholde to separate git-prosjekter. For å gjøre dette, legger jeg til Wiki git repo som en submodul fra hovedgrenen. Hvis du bruker Travis CI eller noe annet CI, må du sørge for at byggverktøyet ignorerer wiki-submodulen. For Travis CI-fil .travis.yml, legg til følgende:
git: submodules: false
Deretter legger du til en git submodule wiki til hovedkodelageret:
$ Git submodule legge [email protected]: [brukernavn] / [repo-name] .wiki.git Kloning i 'hello-team.wiki' ... fjern: Telleobjekter: 6, gjort. fjernkontroll: Komprimering av objekter: 100% (3/3), ferdig. fjernkontroll: Totalt 6 (delta 0), gjenbrukt 0 (delta 0) Motta objekter: 100% (6/6), ferdig. $ git add. $ git commit -m "lagt til wiki som submodule" $ git push origin master
Nå vil wikien vises som en undermodul i hovedkildekodeprosjektet.
Github Hubot
Hubot, kort sagt, kan enormt legge til mye moro i å dokumentere og varsle gruppediskusjoner om viktige forpliktelser.
Hubot er rett og slett en chat bot som kan hente informasjon eller gi beskjed når det er koblet til Github begår, problemer eller aktiviteter. I et lag som forsøker å redusere møter betydelig eller helt eliminere dem, hjelper Hubot med et chatgrensesnitt blant gruppemedlemmene å dokumentere hver eneste diskusjon. Det fremmer absolutt fleksible arbeidstider, da ingen må være til stede samtidig som diskusjoner finner sted. Advarsel: Hubot er veldig vanedannende!
Med dette, la oss begynne med å sette opp Hubot hostet på Heroku og som en bot med Campfire chat-grensesnittet! For både Heroku og Campfire er det gratis versjoner å komme i gang.
Vi vil bruke Githubs Campfire-versjon av Hubot. Hvis du ønsker det, kan du sjekke ut adaptere for andre chatter som Skype, IRC, Gtalk, etc..
Åpne en ny Campfire-konto bare for Hubot, og denne kontoen vil opprette et nytt chatrom som alle andre vil bli invitert til senere.
Distribuere Hubot til Heroku med instruksjonene gitt i Hubot Wiki. Ikke vær redd hvis heroku app url gir a Kan ikke få / som det ikke er noe å få som standard.
Fra Hubot Campfire-kontoen, inviter deg selv. Nå logger du deg på din egen Campfire-konto og utfører Hubot hjelp. Det vil gi deg all ledig kommando for hubot.
Gi noen en prøve, for eksempel hubot send den eller Hubot kart meg CERN.
Deretter legger vi til et Hubot-skript. Det er mange tilgjengelige med kommandobillasjoner.
Som et eksempel vil vi legge til github-commits-skriptet slik at hver gang det er en forpliktelse, vil Hubot varsle oss på chatterommet. Sett filen github-commits.coffee inne i skript mappe.
Oppdater package.json fil med de relevante avhengighetene som instruert på toppen av hver hubot-skriptfil under kommentarer.
Implementer endringene til Heroku igjen med git push heroku master.
Naviger til depotet i Githuben hvis meldingsmelding vil bli vist i chatten. Legg i nettkroken under repoinnstillinger. I tilfelle av det nevnte "github-commit" -skriptet vil webhook være [HUBOT_URL]: [PORT] / hubot / gh-begår rom = [ROOM_ID]?
Neste gang depotet har en forpliktelse, vil Hubot chatte og si det!
Sjekk ut andre Github-relaterte Hubot-skript, eller hvis du vil skrive en, er det også en fin opplæring om det! Hubot, kort sagt, kan enormt legge til mye moro ved å dokumentere og varsle gruppediskusjoner om viktige forpliktelser, problemer og aktiviteter som foregår med Github-repositoriene. Gi det et forsøk!
Som et siste notat om å jobbe med team på Github, er det noen produktivitetstips:
nevner - I et hvilket som helst tekstområde kan vi nevne en annen github-bruker med @bruker og brukeren vil bli varslet om kommentaren
Snarveier - trykk [skifte] + ? for å få tilgang til Github-hurtigtaster på en hvilken som helst side.
Emoji - Ved hjelp av Emoji cheat-arket støtter Github textareas også innføring av ikoner. Gå videre og ha det gøy med lagkamrene dine!
Ikke-programvaresamarbeid på Github
De fleste av oss vil tenke på å bruke Github kun for programvareprosjekter. Tross alt ble Github startet for sosial "koding". Men det er noen kule Github-arkiver som brukes til ikke-kodende prosjekter, og de var like gode for samarbeid og diskusjon. Fordi disse prosjektene også er åpen kildekode og noen kan bidra, er det raskt å fikse feil, enkelt å rapportere feil og effektivt å samarbeide med likesinnede mennesker. Bare for moro skyld, her er noen av dem:
Home Fixes: Problemsporing som overvåkingsverktøy
bøker: Little MongoDB Book, Backbone Fundamentals
lyrics: JSConfEU Lyrics
Finn kjæreste: boyfriend_require
mentoring: Wiki
Genomiske data: Ash Dieback-epidemien
blogger: CSS Wizardry
Og lurer på hva Github-teamet tenker på det?
"Vi graver moro bruk av GitHub som dette"
Flere ressurser
Sosial koding i GitHub, et forskningsarkiv av Carnegie Melon University
Hvordan Github bruker Github til å bygge Github av Zac Holman
Git og Github Secrets av Zac Holman
Nye funksjoner i Github fra Github Blog
Github Help: trekk forespørsler, Fork a Repo
Github funksjoner for samarbeid
Nettuts + Tutorials: Git og Github
Lord of the Files: Hvordan Github Tamed Free Software (og mer) av Wired
Mer morsomt samarbeid!
Så det var en oppfølging av noen samarbeidsverktøy i Github. De fleste av dem tjener som raske analytiske verktøy, eller til og med automatisering som bidrar til å spare tid når du jobber med to eller flere lagkamerater. Har du flere Github tips for lag? La oss dele under!
Share
Accentsconagua
