github projects teams
Denne selvstudie om GitHub forklarer begreber som GitHub-projekter, organisation og teams, gaffel et lager, problemer og projektmilepæle, GitHub Wiki osv .:
I den forrige tutorial af serien af tutorials på GitHub så vi, hvordan en udvikler kan bruge platformen til at gemme de projektrelaterede artefakter og versionskontrol det samme. Vi så også begreberne omkring Pull-anmodninger, Fletning, Forgrening og Beskyttelse af grene.
Nå, det er ikke alt. I denne vejledning vil vi grave dybere og finde ud af, hvad GitHub ellers kan gøre for udviklere.
=> Tjek den perfekte GitHub-træningsvejledning her.
Her er hvad vi vil fokusere på.
- Opret organisation og hold
- Gaffel et lager
- Opret problemer og projektmilepæle
- Opret projektkort
- Oprettelse af GitHub Wiki
Hvad du lærer:
- Opret organisation og hold
- GitHub gaffel
- GitHub-problemer og projektmilepæle
- GitHub Project Board
- GitHub Wiki til dokumentation
- Konklusion
- Anbefalet læsning
Opret organisation og hold
Som formarkør til dette afsnit giver GitHub følgende 3 typer konti.
- Personlige brugerkonti hvor du kan oprette ubegrænsede offentlige og private arkiver og også invitere samarbejdspartnere.
- Organisationskonti som primært er et koncept for delte konti og vil se mere i dette afsnit.
- Virksomhedskonto som bruges af virksomheder, der administrerer politikkerne internt for brugerne ved hjælp af GitHub. Dette bruges typisk i en On-Premise version af GitHub Enterprise.
I del 1 så vi, hvordan et lager blev oprettet ved hjælp af en enkelt personlig konto, hvor den bruger var en enkelt ejer af lageret. Dette er velegnet til små scrum-hold, hvor du har 3 til 9 personer eller måske nogle flere mennesker, eller det er fint at oprette et lager til et enkelt projekt.
Men hvad hvis der er store Github-projekter, der har brug for flere arkiver, og flere teams har adgang til det samme til udførelsen? Her skal vi se på, hvordan GitHub Organisation hjælper med at gruppere flere arkiver til et enkelt stort projekt. Således vil der også være flere ejere, da der ville være flere repositorier / hold involveret.
For at begynde at oprette en ny organisation skal du klikke på + øverst til højre og vælg Ny organisation.
Vælg en plan i overensstemmelse hermed. Vi bruger nu en gratis plan, som er Team for Open Source.
Indtast detaljerne om organisationen, og klik derefter på Næste.
Føj medlemmerne til organisationen, og klik på Fuldfør opsætningen.
Det næste trin er at begynde at oprette arkiver efter projektets behov og tilføje hold til det samme.
Du kan også klikke på Inviter nogen at tilføje medlemmer til den netop oprettede organisation. Når medlemmer tilføjes, kan rollen også tildeles som medlem eller ejer. For at gøre dette gå til Mennesker Tab og vælg Skift rolle for det medlem.
Nå, for nu beholder vi 1 bruger som ejer og den anden som medlem. Således kan ejeren oprette flere arkiver og tildele teams til de respektive arkiver.
Før vi opretter arkiver, skal vi først oprette hold. Gå til Hold fanen og klik på Nyt team.
Vi opretter 2 hold, dvs. UI Team og Middleware Team.
Klik på Opret team. Når holdet er oprettet, kan du tilføje medlemmer til teamet som vist nedenfor.
Opret ligeledes det andet hold og tilføj medlemmer til det. Nu kan du se, at der er 2 hold.
Lad os fortsætte med at oprette arkiver. Så som et scenarie skal vi nu oprette 2 arkiver dvs. en til at holde UI-relateret kode og den anden til at holde middleware-kode. Holdene tildeles i overensstemmelse hermed.
Gå til Opbevaringssteder fanen og opret en Nyt arkiv .
Klik på Opret lager knap. Dernæst er at give UI Team adgang til lageret.
java-metode, der tager en matrix
Gå til Hold fanen. Klik på UI Team og gå til Opbevaringssteder fanen. Klik på hvert hold, og tilføj arkiverne igen fra Opbevaringssteder fanen.
Tilføj arkivet ved at indtaste navnet på lageret.
Sørg også for Skriv tilladelse for teammedlemmerne til dette arkiv, dvs. teammedlemmerne kan læse, klone og skubbe til dette lager.
På samme måde skal du udføre ovenstående trin for at tilføje Middleware-arkivet til det andet hold. Således har vi nu en organisation med repositorier indeni den og holdene også. Teammedlemmerne kan klone det lager, som de har adgang til, og arbejde på det samme.
GitHub gaffel
Gaffel et lager, og hold det synkroniseret med det originale lager.
I de foregående sektioner og den foregående vejledning så vi, at der blev oprettet arkiver, og kildekoden blev tilføjet til den. Hvad nu hvis holdene gerne vil teste nogle kodeændringer, når det originale lager ikke er stedet at gøre det.
Der skal oprettes en kopi for at eksperimentere med eventuelle ændringer i koden ved at holde det originale lager intakt. Dette kaldes GitHub Gaffel . For at oprette en gaffel skal du navigere til lageret, der blev oprettet i den personlige konto og ikke organisationen. Klik på Gaffel øverst til højre.
Vælg den konto, hvor du har brug for at forkaste det originale lager. I dette tilfælde skal du vælge den organisationskonto, hvor lageret forkasseres.
Datalageret er nu forked som Demo-Proj-Org / Demo_Project_Repo_VN . Så alle eksperimenter med koden kan udføres i forked repository og ikke i det originale repository.
Hvis der er foretaget ændringer i det oprindelige lager, skal det forkede lager være i synkronisere . Kommandolinjemuligheder kan bruges til at få det forked-arkiv til at være synkroniseret, men det er en enklere mulighed at oprette en pull-anmodning.
Forudsat at der foretages en ændring af en fil i det originale lager, skal du fortsætte med at oprette en Pull Request.
Klik på linket sammenlign på tværs af gafler.
Vælg hovedet som det originale arkiv og base som det forkede lager som vist, og klik på Opret pull-anmodning.
Klik på Flet pull-anmodning, og bekræft fletningen.
Ændringerne vises i det forgrenede lager og er synkroniseret med det oprindelige lager.
GitHub-problemer og projektmilepæle
Normalt i hvert projekt skal man spore opgaver, mangler, forbedringer osv. Som en del af fremskridtet. Du kan bruge problemerne i GitHub til at spore alle de ovennævnte sammen med Project Boards.
Med problemer kan du knytte det samme til pull-anmodninger, så det automatisk kan lukkes, når pull-anmodningen flettes. Hvis der er åbne problemer, kan de også overføres til andre arkiver. I dette afsnit vil vi se meget mere om, hvordan problemer kan bruges.
Oprettelse af problemer og milepæle
Gå til arkivets hovedside, og gå til Problemer Tab. Klik på Nyt nummer.
Tildel det til en samarbejdspartner at arbejde på, tilføj Label for at skelne som en forbedring. En god praksis er også at nævne om Milepæl at spore fremskridtene i de rejste spørgsmål.
Klik på Indsend et nyt nummer.
Problemoversigten vises. Bemærk, at nummeret på nummeret er nr. 11, som der henvises til senere.
Problemet kan også overføres til et andet arkiv. Muligheden for at gøre det er i bunden 'Overførselsproblem'.
Tilføj en Afleveringsdato til milepælen - R1. Gå til arkivets hovedside Problemer Tab og klik på Milepæle .
Redigere detaljerne til Milestone R1 og tilføj en forfaldsdato. Gem ændringerne, når de er færdige.
Milestone R1 har nu 2 åbne udgaver, og% af færdiggørelsen kan også ses.
Klik på Milepæl R1 for at se de emner, der skal leveres til denne milepæl. Problemer kan også prioriteres igen ved at flytte problemerne op og ned.
Filtrer problemer
Forudsat at der er flere problemer, der er i åben / luk-tilstand og tildelt flere samarbejdspartnere. Det er meget vigtigt at søge efter de spørgsmål, der er baseret på visse kriterier.
For eksempel, alle problemer tildelt dig, alle problemer i åben tilstand osv. GitHub giver søgemuligheden til at filtrere på problemerne og endda trække anmodninger.
Gå til fanen Problemer og i filterboksen indtast kriterierne som følger.
For eksempel er alle åbne udgaver i åben tilstand og tildelt en samarbejdspartner.
type: problemstatus: åben modtager: vniranjan2512 milepæl: R1-etiket: forbedring
Associerede problemer for at trække anmodning
Når der henvises til en Pull-anmodning med et bestemt søgeord og nummer, og når det er slået sammen, lukkes problemet automatisk. Selvom der henvises til en forpligtelse med nøgleord og nummer, lukkes problemet.
Nøgleordet kan være ethvert, dvs. luk, lukker, retter, retter, løser, løser.
For eksempel, i pull anmodningen eller begå besked omtale lukker nr. 11.
Opret en pull-anmodning, og næv nøgleordet & referencenummeret som vist i meddelelsen. Klik på Opret en pull-anmodning og flet.
Problemet lukkes automatisk ved sammenlægning af pull-anmodningen. Lidt af automatisering er absolut nødvendigt.
Opret eller åbn nye problemer fra kildekoden
For eventuelle kodeændringer kan et nyt nummer åbnes. Med dette tilføjes URL'en til linjen med kodeskift til problemet. I en ikke-redigeringstilstand af koden skal du klikke på de 3 prikker (…) ved siden af kodelinjen og vælge Reference i ny udgave .
Oplysninger om problemet opdateret.
hvordan man åbner en .air fil
Pin-udgave
Du kan fastgøre problemet, så det gør det lettere at finde problemerne og også undgå duplikerede problemer fra bliver skabt.
Åbn problemet, og klik i nederste højre hjørne af problemet Pin-problem.
Emnet tilføjes nu over emnelisten.
Bemærk: Maksimalt 3 numre kan fastgøres til enhver tid.
GitHub Project Board
Et projektkort i GitHub giver en nem måde at visualisere problemerne på. Du kan se projektforløbet og se, hvilke problemer der endnu ikke er startet, igangværende og afsluttede udgaver.
Et projektkort i GitHub kan oprettes baseret på Kanban-skabeloner, som har en foruddefineret arbejdsgang og også kan tilpasses. Eksemplet viser et bord oprettet baseret på brugerkontoen.
Gå til arkivets hovedside Projekter fanen og opret en Nyt projekt.
Som du kan se ovenfra, hjælper projektbordet med at:
- Sorter opgaver
- Planlæg dit projekt
- Automatiser din arbejdsgang
- Spor fremskridt
- Del status
- Luk projektet
Nyt projektkort med en grundlæggende Kanban-skabelon.
Tavlen oprettes med en arbejdsgang. Yderligere arbejdsflowkolonner kan også tilføjes ved at klikke på + Tilføj kolonne.
Workflowet kan også automatiseres. For eksempel, Hvis der oprettes et nyt nummer, kan det føjes direkte til Opgavestatus. Vælg Administrer automatisering mulighed for denne status.
Marker afkrydsningsfeltet Nyligt tilføjet og klik på Opdater automatisering. Så når en ny udgave oprettes, føjes det valgte projekt til udgaven automatisk til Opgavestatus. Du kan også trække og slippe det eksisterende problem til status og flytte fra en status til en anden.
Til en kolonne kan du også tilføje noter, som sikrer, at du viser nogle vigtige oplysninger om problemerne i kolonnen. Klik på + underskriv og tilføj en note.
Klik på Tilføje.
GitHub Wiki til dokumentation
En af de meget vigtige aktiviteter i ethvert projekt er at oprette og vedligeholde dokumentation til dit arkiv, som hele teamet kan bruge. GitHub-arkivet leveres med support til oprettelse af sådan dokumentation ved hjælp af GitHub Wiki. Så alle oplysninger om dit projekt og dets anvendelse kan registreres i wiki.
Wikier er gratis tilgængelige for offentlige opbevaringssteder i GitHub. Wikier bruger Open source Markup-bibliotek. Vi vil se, hvordan vi bruger dette bibliotek, mens du skriver wikier.
Aktivering af Wiki-support til arkiv
Klik på arkivets hovedside Indstillinger fanen og sørg for, at Wikier er valgt under Funktioner afsnit.
Opret en GitHub Wiki
Gå til arkivets hovedside Wiki fanen. Klik på Opret den første side.
Indtast en titel, og tilføj tekst til Wiki. Du kan også bruge formateringsindstillingen ved hjælp af Markdown-understøttelse. Klik på Gem side en gang færdig.
Bemærk i ovenstående indhold # er for overskrift1, ## er for overskrift2, ### for overskrift3. * bruges til uordnet notering. Forhåndsvisning vil være som vist nedenfor.
På den Wiki klik på fanen + Tilføj en brugerdefineret sidefod.
Tilføj indholdet, og gem siden.
Åbn enhver gemt Wiki, så ser du sidefoden.
Tilføj sidepanel
Klik på + på fanen wiki Tilføj et tilpasset sidebjælke.
Tilføj indhold til sidebjælken, og gem siden.
Åbn en hvilken som helst wiki, så ser du sidebjælken.
Se Wiki-historie
I historikken kan du se på, hvem der har foretaget ændringen, begå meddelelser og den dato, hvor ændringen blev foretaget.
Åbn Wiki, og rediger siden. Klik på Sidehistorik, på den højre side.
Klik på Hash for at se på ændringerne. Vælg revisionerne for at sammenligne ændringer og gendanne ændringer af en nyere version. Klik på Gendan ændringer.
Ændringerne vender tilbage til den ældre revision.
Bemærk : Du kan tilbagekalde ændringerne baseret på tilladelsen til at redigere Wiki.
Konklusion
I del 1 og del 2 af GitHub-serien har vi set om versionskontrolaktiviteter, oprettelse af arkiver, pullanmodninger, filialer, kodebedømmelser, organisationer og teams, gaffel et lager, etiketter, milepæle, udgaver, GitHub-projekter, Wikis.
I vores kommende vejledning vil vi se på at skabe udgivelser, integration med Jira og få Git kommandoer der vil hjælpe udviklere, før de skubber ændringer til GitHub-arkivet.
Vi håber, at alle udviklerne finder denne praktisk tilgang til GitHub nyttig i deres projekter.
=> Besøg her for den eksklusive GitHub-træningsvejledningsserie.
Anbefalet læsning
- Typer af risici i softwareprojekter
- GitHub-vejledning til udviklere | Sådan bruges GitHub
- Sådan bruges Microsoft TFS til JAVA-projekter med Eclipse i DevOps
- JIRA Agile Tutorial: Sådan bruges JIRA effektivt til styring af agile projekter
- Hvordan adskiller testplanlægningen sig for manuelle og automatiseringsprojekter?
- Eksempler på selenpåstand - Praktiske anvendelser i projekter
- Onsite - Offshore-model af softwaretestprojekter (og hvordan man får det til at fungere for dig)
- Git vs GitHub: Udforsk forskellene med eksempler