github projects teams
Denne opplæringen om GitHub forklarer begreper som GitHub-prosjekter, organisasjon og team, gaffel et lager, problemer og prosjektmilepæler, GitHub Wiki etc:
I den forrige veiledningen i serien veiledninger på GitHub så vi hvordan en utvikler kan bruke plattformen til å lagre prosjektrelaterte gjenstander og versjonskontroll det samme. Vi så også konseptene rundt Pull-forespørsler, Fusjon, forgrening og beskyttelse av grener.
Vel, det er ikke alt. I denne veiledningen vil vi grave dypere og finne ut hva annet GitHub kan gjøre for utviklere.
=> Ta en titt på den perfekte GitHub-treningsveiledningen her.
Her er hva vi vil fokusere på.
- Lag organisasjon og team
- Gaffel et depot
- Lag problemer og prosjekt milepæler
- Lag prosjektbrett
- Opprette GitHub Wiki
Hva du vil lære:
- Lag organisasjon og lag
- GitHub gaffel
- GitHub-problemer og prosjekt milepæler
- GitHub Project Board
- GitHub Wiki for dokumentasjon
- Konklusjon
- Anbefalt lesing
Lag organisasjon og lag
Som en forpeker til denne delen gir GitHub følgende 3 typer kontoer.
- Personlige brukerkontoer hvor du kan opprette ubegrensede offentlige og private arkiver og også invitere samarbeidspartnere.
- Organisasjonskontoer som først og fremst er et konsept med delte kontoer og vil se mer i denne delen.
- Bedriftskonto som brukes av selskaper som administrerer retningslinjene internt for brukerne som bruker GitHub. Dette brukes vanligvis i en lokal versjon av GitHub Enterprise.
I del 1 så vi hvordan et depot ble opprettet ved hjelp av en personlig konto der brukeren var en eier av depotet. Dette er egnet for små scrum-team der du har 3 til 9 personer eller kanskje noen flere mennesker, eller det er greit å lage et lager for et enkelt prosjekt.
Men hva om det er store Github-prosjekter som trenger flere arkiver og flere lag tilgang for det samme for utførelsen? Her må vi se på hvordan GitHub Organization hjelper til med å gruppere flere arkiver for et enkelt stort prosjekt. Dermed vil det også være flere eiere, da det vil være flere repositorier / lag involvert.
For å begynne å opprette en ny organisasjon, klikk på + øverst til høyre og velg Ny organisasjon.
Velg en plan deretter. Vi vil bruke en gratis plan for nå som er Team for åpen kildekode.
Skriv inn detaljene om organisasjonen, og klikk deretter på Neste.
Legg medlemmene til organisasjonen og klikk på Fullstendig oppsett.
Det neste trinnet er å begynne å lage repositorier i henhold til prosjektets behov og legge til team til det samme.
Du kan også klikke på Inviter noen for å legge til medlemmer i organisasjonen nettopp opprettet. Når medlemmer legges til, kan rollen også tildeles som medlem eller eier. For å gjøre dette, gå til Mennesker Tab og velg Endre rolle for det medlemmet.
Vel, for nå vil vi beholde en bruker som eier og den andre som medlem. Dermed kan eieren opprette flere repositories og tildele team til de respektive repositoriene.
Før vi oppretter repositorier, la oss opprette team først. Gå til Lag og klikk på Nytt team.
Vi oppretter to lag, dvs. UI Team og Middleware Team.
Klikk på Lag team. Når laget er opprettet, kan du legge til medlemmer i teamet som vist nedenfor.
På samme måte oppretter du det andre teamet og legger til medlemmer i det. Nå kan du se at det er to lag.
La oss fortsette med å opprette repositorier. Så som et scenario, nå skal vi lage 2 arkiver dvs. en for å ha UI-relatert kode og den andre for å holde mellomvarekode. Lagene tildeles tilsvarende.
Gå til Datalagre kategorien og opprett en Nytt depot .
de beste spillselskapene å jobbe for
Klikk på Opprett depot knapp. Neste er å gi UI Team tilgang til depotet.
Gå til Lag kategorien. Klikk på UI Team og gå til Datalagre kategorien. Klikk på hvert lag og legg til repositoriene igjen fra Datalagre kategorien.
Legg til depotet ved å skrive inn navnet på depotet.
Sørg også for Skriv tillatelse for teammedlemmene til dette depotet, dvs. at teammedlemmene kan lese, klone og presse til dette depotet.
På samme måte gjør du trinnene ovenfor for å legge til Middleware-depotet til det andre teamet. Dermed har vi nå en organisasjon med repositorier innenfor den og teamene også. Teammedlemmene kan klone lagringsområdet de har tilgang til og jobbe med det samme.
GitHub gaffel
Gaffel et depot og hold synkronisering med det originale depotet.
I de forrige seksjonene og den forrige opplæringen så vi lagringsplasser som ble opprettet og kildekoden ble lagt til den. Nå, hva om lagene vil teste noen kodeendringer når det opprinnelige depotet ikke er stedet å gjøre det.
Det må lages en kopi for å eksperimentere med eventuelle endringer i koden ved å holde det originale depotet intakt. Dette kalles GitHub Gaffel . For å opprette en gaffel, naviger til depotet som ble opprettet i den personlige kontoen og ikke organisasjonen. Klikk på Gaffel øverst til høyre.
Velg kontoen der du trenger å punge ut det originale depotet. I dette tilfellet velger du organisasjonskontoen der depotet skal gaffles.
Datalageret er nå forked som Demo-Proj-Org / Demo_Project_Repo_VN . Så, alle eksperimenter med koden kan gjøres i det forgrenede depotet og ikke i det opprinnelige depotet.
Hvis det er gjort noen endringer i det opprinnelige depotet, må det forked-arkivet være i synkronisering . Kommandolinjealternativer kan brukes til å få det forked-arkivet til å være synkronisert, men å opprette en pull-forespørsel er et enklere alternativ.
Forutsatt at det blir gjort en endring av en fil i det opprinnelige depotet, fortsetter du med å opprette en Pull Request.
Klikk på lenken sammenlign på tvers av gafler.
Velg hodet som det opprinnelige depotet og basen som det forked repository som vist, og klikk på Lag trekkforespørsel.
Klikk på Slå forespørsel om sammenslåing og bekreft sammenslåingen.
Endringene vises i gaffelregisteret og er synkronisert med det opprinnelige depotet.
GitHub-problemer og prosjekt milepæler
Normalt i hvert prosjekt, må man spore oppgaver, mangler, forbedringer osv. Som en del av fremdriften. Du kan bruke problemene i GitHub til å spore alle de ovennevnte sammen med prosjektstyrene.
Med problemer kan du knytte det samme til pull-forespørsler, slik at det automatisk kan lukkes når pull-forespørselen slås sammen. Hvis det er åpne problemer, kan de også overføres til andre arkiver. I denne delen vil vi se mye mer om hvordan problemer kan brukes.
Opprette problemer og milepæler
Gå til hovedsiden til depotet og gå til Problemer Tab. Klikk på Ny utgave.
Tilordne det til en samarbeidspartner å jobbe med, legg til etikett for å skille ut som en forbedring. En god praksis er også å nevne om Milepæl for å spore fremdriften i spørsmålene som ble reist.
Klikk på Send inn en ny utgave.
Problemoversikten vises. Vær oppmerksom på at utgivelsesnummeret er nr. 11, som vil bli referert senere.
Problemet kan også overføres til et annet depot. Alternativet for å gjøre det er nederst ‘Transfer issue’.
Legg til en tidsfrist til milepælen - R1. Gå til depotets hovedside Problemer Tab og klikk på Milepæler .
Redigere detaljene for Milestone R1 og legg til en forfallsdato. Lagre endringene når de er gjort.
Milestone R1 har nå to åpne utgaver, og prosentandelen av ferdigstillelse kan også sees.
Klikk på Milestone R1 for å se på problemene som skal leveres for denne milepælen. Problemer kan også prioriteres på nytt ved å flytte problemene opp og ned.
Filtrer problemer
Forutsatt at det er flere problemer som er i Open / Close-tilstand og tilordnet flere samarbeidspartnere. Det er veldig viktig å søke etter de problemene som er basert på visse kriterier.
For eksempel, alle problemer som er tildelt deg, alle problemer i åpen tilstand osv. GitHub gir søkemuligheten for å filtrere på problemene og til og med trekke forespørsler.
Gå til fanen Problemer og i filterboksen skriver du inn kriteriene som følger.
For eksempel, alle åpne problemer i åpen tilstand og tilordnet en samarbeidspartner.
type: problemstatus: åpen rettighetshaver: vniranjan2512 milepæl: R1-etikett: forbedring
Assosierte problemer for å trekke forespørsel
Når det henvises til en Pull-forespørsel med et bestemt søkeord og nummer og når det er slått sammen, lukkes problemet automatisk. Selv om det er referert til en forpliktelse med nøkkelord og nummer, er problemet lukket.
Nøkkelordet kan være hvilket som helst, dvs. lukk, lukker, fikser, fikser, løser, løser.
For eksempel, i pull-forespørselen eller begå melding omtale lukker nr. 11.
Lag en pull-forespørsel og nevn nøkkelordet og referansenummeret som vist i meldingen. Klikk på Lag en pull-forespørsel og slå sammen.
Problemet lukkes automatisk ved sammenslåing av trekkforespørselen. Litt automatisering er absolutt nødvendig.
Opprett eller åpne nye problemer fra kildekoden
For eventuelle kodeendringer kan en ny utgave åpnes. Med dette legges URL til linjen med kodeendring til problemet. I en ikke-redigeringsmodus for koden klikker du på de tre punktene (…) ved siden av kodelinjen og velger Referanse i ny utgave .
dijkstras algoritme som bruker prioritetskø java
Utgavedetaljer oppdatert.
Pin-utgave
Du kan feste problemet slik at det blir lettere å finne problemene og også unngå dupliserte problemer fra blir skapt.
Åpne problemet, og klikk på nederst til høyre i problemet Pin problem.
Utgaven er nå lagt over emnelisten.
Merk: Maksimalt 3 utgaver kan festes når som helst.
GitHub Project Board
Et prosjektbrett i GitHub gir en enkel måte å visualisere problemene på. Du kan se prosjektfremdriften og se på hvilke problemer som ennå ikke skal startes, pågår og fullførte utgaver.
Et prosjektbrett i GitHub kan opprettes basert på Kanban-maler som har en forhåndsdefinert arbeidsflyt og som også kan tilpasses. Eksemplet viser et brett opprettet basert på brukerkontoen.
Gå til depotets hovedside Prosjekter kategorien og opprett en Nytt prosjekt.
Som du kan se ovenfra, hjelper prosjektstyret til å:
- Sorter oppgaver
- Planlegg prosjektet
- Automatiser arbeidsflyten
- Spor fremgang
- Delestatus
- Lukk prosjektet
Nytt prosjektstyr med grunnleggende Kanban-mal.
Brettet er opprettet med en arbeidsflyt. Flere arbeidsflytskolonner kan også legges til ved å klikke på + Legg til kolonne.
Arbeidsflyten kan også automatiseres. For eksempel, Hvis en ny utgave opprettes, kan den legges direkte til Oppgavestatus. Velg Administrer automatisering alternativ for den statusen.
Merk av i avmerkingsboksen Nylig lagt til og klikk på Oppdater automatisering. Så når en ny utgave blir opprettet, legges prosjektet som er valgt for utgaven automatisk til Oppgavestatus. Du kan også dra og slippe det eksisterende problemet til statusen og flytte fra en status til en annen.
I en kolonne kan du også legge til notater som vil sikre at du viser viktig informasjon om problemene i den kolonnen. Klikk på + signer og legg til et notat.
Klikk på Legg til.
GitHub Wiki for dokumentasjon
En av de viktigste aktivitetene i ethvert prosjekt er å lage og vedlikeholde dokumentasjon for depotet ditt slik at hele teamet kan bruke det. GitHub repository kommer med støtte for å opprette slik dokumentasjon ved hjelp av GitHub Wiki. Så all informasjon om prosjektet ditt og bruken av dette kan fanges opp i wiki-en.
Wikier er gratis tilgjengelig for offentlige arkiver i GitHub. Wikier bruker Open source Markup-bibliotek. Vi vil se hvordan du bruker dette biblioteket mens du skriver wikier.
Aktivering av Wiki-støtte for depot
På hovedsiden til depotet klikker du på Innstillinger kategorien og sørg for at Wikier alternativet er valgt under Egenskaper seksjon.
Lag en GitHub Wiki
Gå til depotets hovedside Wiki kategorien. Klikk på Lag den første siden.
Skriv inn en tittel og legg til tekst i Wiki. Du kan også bruke formateringsalternativet ved hjelp av Markdown-støtte. Klikk på Lagre siden en gang ferdig.
Merknad i innholdet ovenfor er # for overskrift1, ## for overskrift2, ### for overskrift3. * brukes til uordnet oppføring. Forhåndsvisning vil være som vist nedenfor.
På Wiki fanen, klikk på + Legg til en tilpasset bunntekst.
Legg til innholdet og lagre siden.
Åpne hvilken som helst lagret Wiki, så ser du bunnteksten.
Legg til sidefelt
Klikk på + i wiki-fanen Legg til et tilpasset sidefelt.
Legg til innhold for sidefeltet og lagre siden.
Åpne hvilken som helst wiki, så ser du sidefeltet.
Se Wiki-historie
I historien kan du se på hvem som gjorde endringen, begå meldinger og datoen da endringen ble gjort.
Åpne Wiki og rediger siden. Klikk på Sidelogg, på høyre side.
Klikk på Hash for å se på endringene. Velg revisjonene for å sammenligne endringer og tilbakestille endringer av en nyere revisjon. Klikk på Tilbakestill endringene.
Endringene blir tilbakeført til den eldre revisjonen.
Merk : Du kan tilbakestille endringene basert på tillatelsen til å redigere Wiki.
Konklusjon
I del 1 og del 2 av GitHub-serien har vi sett om versjonskontrollaktiviteter, oppretting av arkiver, trekkforespørsler, filialer, kodevurderinger, organisasjoner og team, gaffel et lager, etiketter, milepæler, problemer, GitHub-prosjekter, Wikis.
I vår kommende opplæring vil vi se på å lage utgivelser, integrering med Jira og få Git-kommandoer som vil hjelpe utviklere før de skyver endringer i GitHub-depotet.
Vi håper alle utviklerne vil finne denne praktiske tilnærmingen for GitHub nyttig i sine prosjekter.
=> Besøk her for den eksklusive opplæringsserien for GitHub Training.
Anbefalt lesing
- Typer av risikoer i programvareprosjekter
- GitHub-veiledning for utviklere | Hvordan bruke GitHub
- Hvordan bruke Microsoft TFS for JAVA-prosjekter med formørkelse i DevOps
- JIRA Agile Tutorial: Hvordan bruke JIRA effektivt til å administrere smidige prosjekter
- Hvordan er testplanlegging forskjellig for manuelle og automatiseringsprosjekter?
- Eksempler på selenpåstand - Praktiske anvendelser i prosjekter
- På stedet - Offshore-modell av programvaretestprosjekter (og hvordan du får det til å fungere for deg)
- Git vs GitHub: Utforsk forskjellene med eksempler