Oppgavene i prosjektet ligger i et regneark, i en Slack-tråd og i hodet til den som var på møtet i forrige uke. Ingen vet helt hvem som jobber med hva, og når noe er ferdig, må du lete i koden for å finne ut når det skjedde. GitHub Issues og Projects samler alt der koden allerede ligger. Hver oppgave får et nummer, kobles til commitene som løser den, og flytter seg over en tavle etter hvert som arbeidet går.
Hva GitHub Issues er
Fanen Issues i et repo er en oppgaveliste. Hver oppgave, et issue, kan være en feil som skal rettes, en ny funksjon, eller et spørsmål som må avklares. Du ser alle åpne issues, de som er tildelt deg, og de du er nevnt i.
Slik lager du et issue
- Gå til fanen Issues i repoet og klikk New issue.
- Skriv en tittel som sier hva som skal gjøres, for eksempel «Lage header».
- Beskriv oppgaven. Skriv nok til at en annen kan gjøre den uten å spørre deg.
- Velg Assignees, altså hvem som har ansvaret. Assign yourself tildeler den til deg.
- Velg en eller flere Labels for å sortere oppgaven.
- Klikk Create.
Issuet får et nummer, for eksempel #2. Det nummeret er nøkkelen til resten.
Søkefeltet over listen tar filtre, og et par av dem sparer mye leting. is:open assignee:@me viser alle åpne oppgaver som er tildelt deg. is:open label:bug viser alle feil som ikke er rettet. Filtrene kan kombineres, og du kan bokmerke resultatet.
Sorter med labels
Når listen vokser, blir etikettene viktige. GitHub kommer med et ferdig sett: bug, documentation, duplicate, enhancement, good first issue, help wanted, invalid, question og wontfix. Under Edit labels kan du endre farger og navn, slette dem du ikke bruker, og lage egne. Hold settet lite. Ti etiketter alle forstår, er bedre enn førti ingen bruker.
Skal flere oppgaver være ferdige til samme dato, for eksempel en lansering, samler du dem i en milestone. GitHub viser da hvor stor andel av oppgavene som er lukket.
Etikettene good first issue og help wanted har en ekstra funksjon i åpne prosjekter. GitHub bruker dem til å vise frem oppgaver som passer for nye bidragsytere, og det er en god vei inn hvis du vil skaffe deg erfaring ved å bidra i andres prosjekter.
Koble commits til issues
Nevner du nummeret i en commit-melding, kobles commiten til issuet. Skriver du git commit -m "Startet på header #2" og pusher, dukker commiten opp i historikken til issue #2. Da ser alle hvilket arbeid som er gjort på oppgaven, uten å lete.
Er oppgaven ferdig, kan commiten lukke issuet. Skriv close #2, fixes #2 eller resolves #2 i meldingen, og issuet lukkes når commiten pushes.
Obs: Issuet lukkes bare når commiten havner i standardbranchen, som regel main. Pusher du til en feature-branch, skjer det først når branchen blir slått sammen med main.
Issues er også et sted å samarbeide. Står du fast, skriver du en kommentar og tagger en kollega med @brukernavn. Diskusjonen ligger da sammen med oppgaven, ikke i en chat som forsvinner.
Få oversikt med GitHub Projects
En liste over issues sier hva som skal gjøres. Den sier lite om hvor langt hver oppgave har kommet. Det er det GitHub Projects er til for: en tavle i Kanban-stil, slik mange team kjenner fra Scrum.
- Gå til fanen Projects og klikk New project.
- Velg malen Kanban.
- Gi prosjektet et navn, og velg å importere issuene du allerede har.
- Klikk Create project.
Issuene dukker opp i kolonnen Backlog. Derfra flytter du dem videre til Ready, In progress, In review og Done. Du kan dra kortene mellom kolonnene, eller endre Status under Projects i sidepanelet til et issue. Prosjektlederen ser til enhver tid hvem som jobber med hva, uten å spørre.
Tavlen kan også flytte kortene selv. Prosjektene har innebygde automatiseringer, slik at et issue som lukkes, eller en pull request som slås sammen, havner i Done. Kobler du commit-meldinger, pull requests og tavlen sammen, holder oversikten seg oppdatert mens du jobber.
En arbeidsflyt som holder
- Lag et issue for alt som tar mer enn noen minutter. Små oppgaver er lettere å estimere, tildele og lukke.
- Lag en branch per issue, med nummeret i navnet. I issuet finner du Create a branch under Development.
- Nevn nummeret i alle commits, og skriv «Closes #2» i pull requesten.
- Bruk tavlen i stand-up. Se på In progress og In review, ikke på hele backloggen.
Hvordan branchen blir til en pull request og en godkjent code review, står i Slik gjør du code review i GitHub. Vil du jobbe raskere med commitene, er Slik bruker du git status, git add og git commit et godt sted å starte. Nøkkelordene som lukker issues, står i GitHubs dokumentasjon om å koble pull requests til issues.
Denne videoen er hentet fra kurset Git og GitHub på Utdannet.no. I det fulle kurset lager du issues med etiketter, kobler commits til dem, lukker et issue fra terminalen, og setter opp en Kanban-tavle i GitHub Projects som oppdaterer seg selv når en pull request blir godkjent.
