GitHub is de hoeksteen geworden voor open source software voor alle dingen. Ontwikkelaars zijn er dol op, werken eraan samen en bouwen er doorlopend geweldige projecten mee. Afgezien van het hosten van onze code, is GitHub's grootste attractie het gebruik ervan als een hulpmiddel voor samenwerking. In deze zelfstudie laten we enkele van de nuttigste GitHub-functies verkennen, vooral voor teams, waardoor deze nog efficiënter, productiever en vooral leuk is!
Github en software-samenwerking
Een ding dat ik erg handig vind is het integreren van de Github Wiki in het belangrijkste broncodeproject.
Deze tutorial gaat ervan uit dat je al bekend bent met Git, het open source gedistribueerde versiebeheersysteem, gemaakt door Linus Torvalds in 2005. Als je een herziening of een opzoekactie op Git nodig hebt, bezoek dan onze vorige screencastcursus of zelfs enkele berichten. Je zou ook al een Github-account moeten hebben en een aantal basisfuncties moeten uitvoeren, zoals het maken van een repository en het pushen van wijzigingen naar Github. Als dat niet het geval is, ga dan verder met eerdere tutorials.
In de wereld van softwareprojecten is het onvermijdelijk dat we in een team werken om een project te realiseren. Voor deze tutorial over Github en teamsamenwerking zullen we een aantal van de meest gebruikelijke tools verkennen die we doorgaans nodig hebben bij het werken met softwareteams. De besproken hulpmiddelen zijn:
Teamleden toevoegen - Organisatie en bijdragers
Pull-verzoeken - Verzenden en samenvoegen
Bug Tracking - Github-problemen
Analytics - Grafieken & netwerk
Project management - Trello & Pivotal Tracker
Continue integratie - Travis CI
Code Review - Lijnreacties en URL-query's
documenteren - Wiki & Hubot
Liever een Screencast?
Als u de voorkeur geeft aan een screencast voor een visuele doorloop, spring dan net onder om het te bekijken en raadpleeg deze tutorial als kanttekeningen:
Download video
Tool 1: Teamleden toevoegen
Er zijn over het algemeen twee manieren om Github in te stellen voor teamsamenwerking:
organisaties - Organisatie-eigenaar kan veel teams maken met verschillende machtigingsniveaus voor verschillende repositories
medewerkers - Repository-eigenaar kan bijdragers toevoegen met Read + Write-toegang voor een enkele repository
organisaties
Als u meerdere teams begeleidt en u wilt verschillende machtigingsniveaus instellen voor elk team met verschillende leden en elk lid toevoegen aan verschillende opslagplaatsen, dan is Organisatie de beste optie. Elk Github-gebruikersaccount kan al gratis organisaties maken voor open broncode-repository's. Als u een organisatie wilt maken, bladert u eenvoudig naar de instellingenpagina van uw organisatie:
Om toegang te krijgen tot de teams-pagina voor uw organisatie, kunt u gewoon naar http://github.com/organizations/[organization-name]/teams om ze te bekijken of zelfs te bezoeken https://github.com/organizations/[organization-name]/teams/new om nieuwe teams te maken met leden van 3 verschillende bevoegdheidsniveaus, zoals:
Trek alleen: Ophalen en samenvoegen met een andere repository of een lokale kopie. Alleen-lezen toegang.
Duwen en trekken: (1) samen met het bijwerken van remote repo. Lezen + Schrijven toegang.
Push, Pull & Administratief: (1), (2) samen met rechten op factureringsinformatie, het maken van teams en het annuleren van organisatieaccounts. Lezen + Schrijven + Beheerderstoegang
medewerkers
Medewerkers zijn gewend om beide te geven Lezen + Schrijven toegang naar een enkele repository die eigendom is van een persoonlijk account. Als u bijdragers wilt toevoegen (andere persoonlijke Github-accounts), gaat u gewoon naar https://github.com/[username]/[repo-name]/settings/collaboration:
Zodra dat is gebeurd, ziet elke bijdrager vervolgens een wijziging in de toegangsstatus op de repositorypagina. Nadat we schrijftoegang tot de repository hebben, kunnen we a git clone, werk aan de veranderingen, maak een git pull om eventuele wijzigingen in de externe repository en uiteindelijk op te halen en samen te voegen git push, om de externe repository te updaten met onze eigen wijzigingen:
Tool 2: Pull Requests
Pull-verzoeken zijn een geweldige manier om zelfstandig bij te dragen aan een repository door het te formuleren. Aan het einde van de dag kunnen we, als we dat willen, een pull-aanvraag sturen naar de eigenaar van de repository om onze codeveranderingen samen te voegen. Het pull-verzoek op zich kan vervolgens discussies afvuren voor codekwaliteit, functies of zelfs algemene strategie.
Laten we nu de basisstappen voor een pull-aanvraag bekijken.
Een pull-aanvraag starten
Er zijn twee modellen van pull-aanvragen in Github:
Vork & Pull-model - Gebruikt in een openbare repository waarvoor we geen push-toegang hebben
Share Repository Model - Gebruikt in een privé-repository waarvoor we push-toegang hebben. Vork is niet vereist, is dit geval.
Hier zien we de workflow tussen twee gebruikers (repo-eigenaar en gevorkte-repo-eigenaar) voor het vork- en trekmodel:
Identificeer de Github Repository waaraan u een bijdrage wilt leveren en klik op de knop "Vork" om een kloon van de repository te maken in uw eigen Github-account:
Hiermee maakt u een exacte kopie van de repository in uw eigen account
Kies de SSH-URL zodat deze elke keer dat u wordt gevraagd om uw wachtwoordzin voor SSH-sleutels vraagt in plaats van de gebruikersnaam en het wachtwoord git push of git pull. Vervolgens zullen we deze repository klonen naar onze lokale computer:
$ git clone [ssh-url] [folder-name] $ cd [folder-name]
Over het algemeen zullen we voor elke nieuwe functie een nieuwe git branch maken. Dit is een goede gewoonte, want in de toekomst zullen we, als we de tak na een aantal discussies verder bijwerken, automatisch de pull-aanvraag bijwerken. Laten we een nieuwe branch maken om een heel eenvoudige wijziging aan te brengen in de readme.md het dossier:
$ git checkout -b [nieuwe functie]
Na het maken van de relevante toevoegingen om de nieuwe functies te bouwen, zullen we gewoon de nieuwe wijzigingen toewijzen en uitchecken naar de git master branch:
Op dit punt zullen we de branch naar de externe repository duwen. Hiervoor controleren we eerst de filternaam met de nieuwe functie en de externe repositoryaliassen op git. Dan zullen we de veranderingen gebruiken met git push [git-remote-alias] [filiaalsnaam]:
In onze Github-pagina met gevorkte repository gaan we naar de branch met de nieuwe functie en klikken op de knop 'Pull Request'.
Nadat we de pull-aanvraag hebben ingediend, worden we direct naar de pull-requestpagina van de oorspronkelijke repository gebracht. We zullen ons pull-verzoek zien, zowel als een nieuw probleem als een nieuw pull-verzoek.
Na de discussie is het mogelijk dat de eigenaar van de gevorkte repository wijzigingen in de nieuwe functie wil toevoegen. In dit geval gaan we naar dezelfde vestiging op onze lokale computer, verbinden we het en duwen het terug naar Github. Wanneer we de pull-aanvraagpagina van de oorspronkelijke repository bezoeken, wordt deze automatisch bijgewerkt!
Een Pull-aanvraag samenvoegen
Als u de oorspronkelijke eigenaar van de opslagplaats bent, zijn er twee manieren om een binnenkomende pull-aanvraag samen te voegen:
Direct samenvoegen op Github: Als we direct in Github samenvoegen, zorg dan dat er geen conflicten zijn en het is klaar om te worden samengevoegd met de hoofdtak. De eigenaar van de oorspronkelijke repository kan eenvoudig op de groene knop "Merge Pull Request" klikken om dit te doen:
Samenvoegen in onze lokale machines: Op andere momenten kunnen er samenvoegconflicten zijn. Als u op de knop 'info' klikt, heeft Github duidelijke instructies over hoe we de branch kunnen samenvoegen in onze lokale machine door de wijzigingen van de filiaal van de bijdrager over te nemen:
Er zijn verschillende vertakkingsmodellen gebruikt voor versiebeheer in softwareontwikkelingsteams. Hier zijn twee populaire git workflow-modellen: (1) Github-workflow met een eenvoudig vertakkingsmodel en pull-requests en (2) Gitflow met een meer uitgebreide vertakking. Het uiteindelijk gekozen model zal zeker variëren, afhankelijk van het team, het project en de situatie.
Tool 3: Bug-tracking
Pull-verzoeken zijn een geweldige manier om zelfstandig bij te dragen aan een repository door het te formuleren.
In Github is het centrum voor alle bug-tracking de problemen. Ook al zijn ze vooral bedoeld voor het bijhouden van bugs, het is ook handig om problemen op de volgende manieren te gebruiken:
bugs: Dingen die duidelijk kapot zijn en reparaties nodig hebben
Kenmerken: Geweldige coole nieuwe ideeën om te implementeren
Te doen lijst: Een checklist met items om in te vullen
Laten we enkele functies van problemen onderzoeken:
labels: Het zijn gekleurde categorieën voor elk probleem. Ze zijn nuttig voor het dienovereenkomstig filteren van problemen.
Mijlpalen: Het zijn gedateerde categorieën die aan elk probleem kunnen worden gekoppeld en zijn nuttig om te bepalen aan welke problemen moet worden gewerkt voor de volgende release. Aangezien mijlpalen zijn gekoppeld aan problemen, wordt de voortgangsbalk automatisch bijgewerkt bij het sluiten van elk bijbehorend probleem.
Zoeken: Zoek automatisch naar zowel problemen als mijlpalen
opdracht: Elk probleem kan worden toegewezen aan een verantwoordelijke persoon om het probleem op te lossen. Het is een andere handige functie om te zien waaraan we moeten werken.
Auto-close: Commit-berichten met Oplossing / Vast of Sluiten / Sluiten / Gesloten # [uitgavennummer] sluit het probleem automatisch.
vermeldt: Iedereen kan ook een notitie achterlaten door alleen maar aan te geven #[uitgave nummer] in hun berichten. Omdat de probleemnummers met een hyperlink worden weergegeven, is het eenvoudig om gerelateerde problemen tijdens de discussie te vermelden.
Hulpprogramma 4: analyse
Het is duidelijk dat we onze takenlijst en updates van onze code commits stevig kunnen koppelen.
Er zijn twee tools die inzicht geven in een repository - Grafieken en netwerken. Github Graphs biedt inzicht in de bijdragers en committeert achter elke coderepository, terwijl Github Network een visualisatie biedt voor alle bijdragers en hun commits in alle gevorkte repositories. Deze analyses en grafieken worden zeer krachtig, vooral wanneer er in teams wordt gewerkt.
grafieken
Grafieken bieden gedetailleerde analyses, zoals:
medewerkers: Wie waren de bijdragers? En hoeveel regels code ze hebben toegevoegd of verwijderd?
Commit activiteit: In welke weken hebben de commits het afgelopen jaar plaatsgevonden??
Code Frequentie: Hoeveel codecodes zijn er tijdens de volledige levenscyclus van het project vastgelegd?
Ponskaart: In welke tijden van de dag vinden de commits meestal plaats?
Netwerk
Github Network is een krachtige tool waarmee je elke commit van elke bijdrager kunt zien en hoe deze gerelateerd is aan elkaar. Wanneer we de visualizer in zijn geheel bekijken, zien we elke commit op elke tak van elke repository die tot een netwerk behoort. Inzichtelijk!
Tool 5: projectbeheer
Hoewel Github Issues projectbeheermogelijkheden met problemen en mijlpalen heeft, geven sommige teams misschien de voorkeur aan een ander hulpmiddel vanwege andere functies of bestaande workflow. In deze sectie zullen we zien hoe we Github kunnen koppelen aan twee andere populaire projectmanagementtools: Trello en Pivotal Tracker. Met Github-servicehaken kunnen we de updating-taak automatiseren met commits, problemen en vele andere activiteiten. Deze automatisering helpt niet alleen tijd te besparen, maar vergroot ook de nauwkeurigheid van updates voor elk softwareontwikkelingsteam.
Github en Trello
Trello biedt een eenvoudige, visuele manier om taken te beheren. Met Agile Software Development-methodologieën kunnen Trello-kaarten een eenvoudig virtueel Kanban-bord emuleren. We zullen bijvoorbeeld automatisch een Trello-kaart maken wanneer een Pull-aanvraag wordt gedaan met Github Service Hooks. Laten we de stappen doorlopen!
Open een account in Trello als je er nog geen hebt en maak een nieuw Trello-bord.
Ga naar de Github-repository> Instellingen> Service Hooks> Trello
Pak de TOKEN onder Installeren Nota's # 1 met de verstrekte hyperlink voor authenticatie.
Gebruik onder Install Notes 2 de gegeven URL om een json-geformatteerde structuur te genereren die ons de lijst id voor elke Trello-kaart. BOARDID maakt deel uit van de URL wanneer we het bord bezoeken op https://trello.com/board/[BOARD-NAME]/[BOARDID]. TOKEN kan worden gemaakt met de hyperlink gegeven onder Install Notes # 1.
Terug in de Github servicehaken, doe de lijst id en de blijk. Controleer Actief, Test Hook en we zijn klaar om automatische updates te krijgen telkens wanneer er een Pull Request is.
De volgende keer dat er een Pull Request is, heeft de Pull Request Trello-kaart automatisch een nieuw item!
Github en Pivotal Tracker
Pivotal Tracker is een andere lichtgewicht agile projectbeheertool waarbij op verhaal gebaseerde planning het team toelaat om gemakkelijk samen te werken door direct te reageren op verschillende veranderingen en voortgang van het project. Op basis van de huidige voortgang van het team, kan het ook diagrammen maken om de teamsnelheid, iteratie-burn-up, release-burn-down, enz. Te analyseren. In dit korte voorbeeld zullen we automatisch een verhaal weergeven door het te koppelen aan een Github commit!
Maak een nieuw project in de Pivotal Tracker met een nieuw verhaal dat moet worden geleverd.
Ga naar Profiel> API-token (helemaal onderaan). Kopieer het gegeven API-token.
Keer terug naar Github-repository> Instellingen> Servicehaken> Pivotal Tracker. Plak het token, vink Actief aan en klik op Instellingen bijwerken. We zijn er helemaal klaar voor om automatisch Pivotal Tracker Stories met Github Commits te leveren!
Ten slotte zullen we onze wijzigingen doorvoeren en de tracker-ID toevoegen aan het commit-bericht met het formaat git commit -m "-bericht [levert #tracker_id]"
Nu, wanneer we teruggaan naar de Pivotal Tracker, zullen we zien dat het verhaal automatisch is geleverd met links naar de exacte Github-commit die de bestandswijzigingen laat zien!
Met deze voorbeelden van Trello en Pivotal Tracker is het duidelijk dat we onze takenlijst en updates van onze code-commits stevig kunnen koppelen. Dit is een enorme tijdbesparing bij het werken in een team en het verbetert de nauwkeurigheid bij het koppelen van taken aan de exacte commits. Het goede nieuws is dat als u al andere hulpprogramma's voor projectbeheer, zoals Asana, Basecamp en anderen, ook op een vergelijkbare manier servicehaken kunt maken. Als er geen bestaande Service Hooks voor uw huidige projectmanagementtool zijn, kunt u er zelfs een maken!
Tool 6: continue integratie
Continuous Integration (CI) is een belangrijk onderdeel van alle softwareontwikkelingsprojecten die met teams werken. CI zorgt ervoor dat wanneer een ontwikkelaar zijn code incheckt, een geautomatiseerde build (inclusief tests) integratiefouten zo snel mogelijk detecteert. Dit vermindert absoluut integratiefouten en maakt snelle iteratie veel efficiënter. In dit voorbeeld zullen we zien hoe Travis CI kan worden gebruikt met Github voor CI om fouten te detecteren en aan te bevelen samen te voegen wanneer alle tests worden doorstaan.
Travis CI instellen
We zullen een eenvoudig "hello-world" -project gebruiken voor node.js met grunt.js als de build-tool voor het opzetten van een Travis CI-project. Dit zijn de bestanden in het project:
De hello.js bestand is het knooppuntproject. Hier zullen we opzettelijk een puntkomma weglaten zodat het de grunt build tool voor pluizen niet zal passeren:
var http = require ('http'); http.createServer (functie (req, res) res.writeHead (200, 'Content-type': 'text / plain'); res.end ('Hello World in Node! \ n') // zonder puntkomma , dit zal niet doorgaan met pluizen). listen (1337, '127.0.0.1'); console.log ('Server draait op http://127.0.0.1:1337/');
package.json geeft de afhankelijkheden aan:
"name": "hello-team", "description": "Een demo voor github en travis ci voor teamsamenwerking", "auteur": "naam "," version ":" 0.0.1 "," devDependencies ": " grunt ":" ~ 0.3.17 "," scripts ": " test ":" grunt travis --verbose "
De gruntjs bouwtool heeft slechts één taak (pluizen) voor de eenvoud:
.travis.yml is een Travis-configuratiebestand waardoor Travis onze tests uitvoert:
taal: node_js node_js: - 0.8
Meld u vervolgens aan bij Travis met uw Github-account en schakel de haak van de gegevensopslagruimte onder het tabblad van de repository in.
Als de stap ervoor de build niet activeert, moeten we de servicehaak handmatig instellen. Om het handmatig in te stellen, kopieert u het token onder het profieltabblad.
Ga terug naar de Github-repository om de Github Travis-servicehaken met het token in te stellen.
Voor de eerste keer moeten we een handleiding maken git push om de eerste Travis-build te activeren en als alles in orde is, ga je gewoon naar http://travis-ci.org/[username]/[repo-name] om de build-status als passerend te zien!
Travis-CI met pull-aanvragen
Eerder, zonder enige CI in het proces van een pull-aanvraag, gingen de stappen ongeveer zo (1) verzonden pull-request (2) merge (3) testen om te zien of het slaagt / faalt. Met Travis CI gekoppeld aan de pull-aanvragen, kunnen we de stappen 2 en 3 omkeren, waardoor de snelle besluitvorming over het al dan niet goed fuseren met Travis, die ons de status geeft bij elke pull-aanvraag, wordt verhoogd. Laten we kijken hoe we dat kunnen laten gebeuren.
Stuur een Pull Request met een passerende build en Travis doet zijn magie om je te laten weten dat het goed is om samen te voegen, zelfs voordat je samenvoegt
Als het Pull-verzoek mislukt, zal Travis je ook waarschuwen.
Als we op de rode waarschuwingsknop klikken, wordt er ook een link naar de travispagina gemaakt om ons de details van de build te tonen.
Travis CI met Github is enorm nuttig voor teams vanwege geautomatiseerde builds en onmiddellijke melding. Het maakt de foutcorrectiecyclus zeker een stuk korter. Als u Jenkins, een andere populaire CI-tool, gebruikt, kunt u Github-servicehaken op dezelfde manier instellen.
Tool 7: Code Review
Met elke commit kan Github een duidelijke interface bieden voor algemene opmerkingen of zelfs specifieke opmerkingen over een regel code. De mogelijkheid om opmerkingen of vragen te stellen op elke regel code is erg handig bij het doen van regel voor regel code-evaluaties. Als u de inline-opmerkingen wilt weergeven, schakelt u het selectievakje aan de bovenkant van elke commit in of uit.
Laten we enkele URL-patronen verkennen die kunnen worden gebruikt om ons te helpen bij het beoordelen van codes door ons snel de verschillen tussen commits te geven:
Vergelijk branches / tags / SHA1 : gebruik het URL-patroon https://github.com/[gebruikersnaam]/[repo-name]/compare/[starting-SHA1]... [ending-SHA1]. Je kunt hetzelfde doen met branch of tags.
Vergelijk zonder witruimte : toevoegen ?w = 1 naar de vergelijkings-URL's
diff : toevoegen .diff naar de vergelijkings-URL's om de git diff informatie in platte tekst. Dit kan handig zijn voor scriptdoeleinden.
lap : toevoegen .lap naar de vergelijkings-URL's om de git diff informatie opgemaakt voor het indienen van e-mailpatches.
Line Linking : Wanneer we in een bestand op het regelnummer klikken, voegt Github er een toe #lijn aan het einde van de URL en maak de achtergrondkleur van de hele regel als geel. Dit is leuk om op de exacte regel te wijzen. Het accepteert ook regelbereiken door toe te voegen #begin het einde. Hier zijn voorbeelden van het linken van lijnen en lijnbereik.
Tool 8: documenteren
In deze sectie zullen we twee documentatiemethoden onderzoeken:
Formele documentatie: Github Wiki om documentatie voor de broncode te maken
Informele documentatie: Github Hubot documenteert discussies tussen teamleden en automatiseert het ophalen van informatie door interactie met een leuke chat-bot!
Mentions, Shortcuts & Emoji
Github Wiki
Met elke repository kan een Github Wiki worden gemaakt, en dit kan uitermate handig zijn om zowel de broncode als de documentatie onder dezelfde repository te plaatsen. Om de Wiki te maken, gaat u naar het tabblad Wiki in de hoofdkop en u bent ingesteld om pagina's met informatie te maken. De Wiki zelf heeft zijn eigen versiebeheer en de gegevens kunnen worden gekloond naar onze lokale computer voor updates of zelfs offline toegang.
Een ding dat ik erg handig vind is het integreren van de Github Wiki in het belangrijkste broncodeproject, zodat ik geen twee afzonderlijke git-projecten hoef te onderhouden. Om dit te doen, voeg ik de Wiki git repo toe als een submodule van de master branch. Als u Travis CI of een andere CI gebruikt, moet u ervoor zorgen dat de build-tool de wiki-submodule negeert. Voor Travis CI-bestand .travis.yml, voeg het volgende toe:
git: submodules: false
Voeg vervolgens een git-submodule-wiki toe aan de hoofdcode-repository:
$ git submodule add [email protected]: [gebruikersnaam] / [repo-naam] .wiki.git Klonen in 'hello-team.wiki' ... remote: Tellen van objecten: 6, klaar. afstandsbediening: objecten comprimeren: 100% (3/3), gereed. remote: Total 6 (delta 0), reused 0 (delta 0) Ontvangende objecten: 100% (6/6), klaar. $ git add. $ git commit -m "voegde wiki toe als submodule" $ git push origin master
Nu zal de Wiki netjes verschijnen als een submodule binnen het hoofdproject van de broncode.
Github Hubot
Hubot kan, kort gezegd, enorm veel plezier toevoegen aan het documenteren en informeren van teambesprekingen over belangrijke commits.
Hubot is gewoon een chat-bot die informatie kan ophalen of een melding kan geven als deze is verbonden met Github-commits, problemen of activiteiten. In een team dat probeert vergaderingen aanzienlijk te verminderen of zelfs volledig te elimineren, helpt Hubot met een chatinterface tussen de teamleden om elke afzonderlijke discussie te documenteren. Het bevordert zeker flexibele werktijden, omdat niemand tegelijkertijd aanwezig hoeft te zijn om te discussiëren. Waarschuwing: Hubot is vreselijk verslavend!
Laten we hiermee beginnen met het instellen van Hubot gehost op Heroku en als een bot met de Campfire-chatinterface! Voor zowel Heroku als Campfire zijn er gratis versies om aan de slag te gaan.
We zullen Github's Campfire-versie van Hubot gebruiken. Als u wilt, kunt u adapters bekijken voor andere chats, zoals Skype, IRC, Gtalk, enz.
Open een nieuw Campfire-account alleen voor de Hubot en dit account zal een nieuwe chatruimte maken waar iedereen later voor uitgenodigd zal worden.
Implementeer Hubot naar Heroku met de instructies in de Hubot Wiki. Wees niet gealarmeerd als de URL van de heroku-app een geeft Kan niet krijgen / want er is standaard niets te krijgen.
Nodig jezelf uit vanuit het Hubot Campfire-account. Log nu in op uw eigen Campfire-account en voer het uit Hubot-hulp. Het geeft je alle beschikbare commando's voor hubot.
Probeer het eens, zoals hubot verzend het of hubot kaart me CERN.
Vervolgens zullen we een Hubot-script toevoegen. Er zijn veel dingen beschikbaar met afbeeldingen met opdrachten.
We zullen bijvoorbeeld het script github-commits toevoegen, zodat elke keer als er een commit is, Hubot ons op de hoogte stelt in de chatroom. Zet het bestand github-commits.coffee binnen in de scripts map.
Bijwerken package.json bestand met de relevante afhankelijkheden zoals aangegeven boven elk hubot-scriptbestand onder opmerkingen.
Implementeer de wijzigingen opnieuw in Heroku met git push heroku master.
Navigeer naar de repository in de Github waarvan de commitmelding in de chat wordt weergegeven. Voeg de webhaak toe onder repo-instellingen. In het geval van het genoemde "github-commit" -script zal de webhook zijn [HUBOT_URL]: [PORT] / hubot / GH-begaat kamer = [ROOM_ID]?
De volgende keer dat de repository een commit heeft, zal de Hubot een gesprek voeren en dat zeggen!
Afrekenen met andere Github-gerelateerde Hubot-scripts, of als je er een wilt schrijven, daar is ook een leuke tutorial over! Kortom, hubot kan enorm veel plezier toevoegen bij het documenteren en informeren van teambesprekingen over belangrijke commits, problemen en activiteiten die plaatsvinden met onze Github-opslagplaatsen. Probeer het eens!
Als laatste opmerking over het werken met een team voor Github, volgen hier een aantal productiviteitstips:
vermeldingen - In elk tekstgebied kunnen we een andere github-gebruiker vermelden @gebruiker en de gebruiker krijgt een melding van de reactie
Sneltoetsen Keys - druk op [verschuiving] + ? voor toegang tot Github sneltoetsen op elke pagina.
Emoji - Met het Emoji-spiekbriefje ondersteunt Github-tekstgebieden ook het invoegen van pictogrammen. Ga je gang en heb plezier met je teamgenoten!
Niet-software samenwerking op Github
De meesten van ons zullen denken om Github alleen te gebruiken voor softwareprojecten. Github is immers gestart voor sociale "codering". Maar er zijn enkele coole Github-repository's die worden gebruikt voor niet-coderende projecten, en ze waren even geweldig voor samenwerking en discussie. Omdat deze projecten ook open source zijn en iedereen een bijdrage kan leveren, is het snel om fouten op te lossen, eenvoudig bugs te melden en effectief om samen te werken met gelijkgestemde mensen. Gewoon voor de lol, hier zijn enkele van hen:
Home Fixes: Probleemopsporing als monitoringtool
Boeken: Little MongoDB Book, Backbone Fundamentals
Lyrics: JSConfEU Lyrics
Vind Boyfriend: boyfriend_require
mentoring: wiki
Genomische gegevens: Ash Dieback-epidemie
blogs: CSS-tovenaar
En vraag me af wat het Github-team erover denkt?
"We graven leuke gebruiken van GitHub op deze manier"
Meer middelen
Social Coding in GitHub, een research paper van de Carnegie Melon University
Hoe Github Github gebruikt om Github door Zac Holman te bouwen
Git en Github Secrets door Zac Holman
Nieuwe functies in Github van de Github-blog
Github Help: verzoeken trekken, een Repo invullen
Github-functies voor samenwerking
Nettuts + tutorials: Git en Github
Lord of the Files: hoe Github Tamired vrije software (en meer) behe
Share
Accentsconagua
