github projects teams
Deze tutorial over GitHub legt concepten uit zoals GitHub-projecten, organisatie en teams, Fork a Repository, problemen en projectmijlpalen, GitHub Wiki enz.:
In de vorige tutorial van de reeks tutorials over GitHub, hebben we gezien hoe een ontwikkelaar het platform kan gebruiken om de projectgerelateerde artefacten en versiebeheer op dezelfde manier op te slaan. We zagen ook de concepten rond Pull-verzoeken, Merging, Branching en Protecting branches.
Nou, dat is niet alles. In deze tutorial zullen we dieper graven en ontdekken wat GitHub nog meer voor ontwikkelaars kan doen.
Bekijk hier de perfecte GitHub-trainingsgids.
Hier is waar we ons op zullen concentreren.
- Maak een organisatie en teams
- Fork een repository
- Creëer problemen en projectmijlpalen
- Maak een projectbord
- GitHub Wiki maken
Wat je leert:
- Maak een organisatie en teams
- GitHub Fork
- GitHub-problemen en projectmijlpalen
- GitHub-projectbord
- GitHub Wiki voor documentatie
- Gevolgtrekking
- Aanbevolen literatuur
Maak een organisatie en teams
Als een pre-cursor op deze sectie biedt GitHub de volgende 3 soorten accounts.
- Persoonlijke gebruikersaccounts waarin u onbeperkte openbare en privé-repositories kunt maken en ook bijdragers kunt uitnodigen.
- Organisatie-accounts Dit is voornamelijk een concept van gedeelde accounts en zal in deze sectie meer zien.
- Enterprise-account die wordt gebruikt door bedrijven die het beleid intern beheren voor de gebruikers die GitHub gebruiken. Dit wordt meestal gebruikt in een on-premise-versie van de GitHub Enterprise.
In deel 1 hebben we gezien hoe een repository werd gemaakt met één persoonlijk account waarbij die gebruiker één eigenaar van de repository was. Dit is geschikt voor kleine scrum-teams waar je 3 tot 9 mensen hebt of misschien wat meer mensen, of om een repository voor een enkel project te maken is prima.
Maar wat als er grote Github-projecten zijn die meerdere repositories nodig hebben en meerdere teams toegang hebben voor dezelfde voor de uitvoering? Hier moeten we kijken hoe GitHub Organization helpt bij het groeperen van meerdere repositories voor één groot project. Er zullen dus ook meerdere eigenaren zijn omdat er meerdere repositories / teams bij betrokken zijn.
Om een nieuwe organisatie aan te maken, klikt u op de rechtsboven en selecteer Nieuwe organisatie.
Selecteer dienovereenkomstig een plan. We zullen voorlopig een gratis abonnement gebruiken Team voor Open Source.
Voer de gegevens over de organisatie in en klik op De volgende.
Voeg de leden toe aan de organisatie en klik op Voltooi de installatie.
De volgende stap is om te beginnen met het maken van opslagplaatsen volgens de projectbehoeften en hier teams aan toe te voegen.
U kunt ook op klikken Iemand uitnodigen om leden toe te voegen aan de zojuist gemaakte organisatie. Als er leden worden toegevoegd, kan de rol ook worden toegewezen als lid of eigenaar. Ga hiervoor naar het Mensen Tab en selecteer Rol wijzigen voor dat lid.
beste gratis registry cleaners voor windows 10
Welnu, voorlopig behouden we 1 gebruiker als Eigenaar en de andere als lid. Zo kan de eigenaar meerdere repositories aanmaken en teams aan de respectievelijke repositories toewijzen.
Laten we eerst teams maken voordat we opslagplaatsen maken. Ga naar het Teams tab en klik op Nieuw team.
We zullen 2 teams maken, d.w.z. UI Team en Middleware Team.
Klik op Creëer een team. Nadat het team is gemaakt, kunt u leden aan het team toevoegen zoals hieronder weergegeven.
Maak op dezelfde manier het andere team en voeg er leden aan toe. Nu kun je zien dat er 2 teams zijn.
Laten we doorgaan met het maken van opslagplaatsen. Dus nu gaan we als scenario creëren 2 opslagplaatsen d.w.z. een om UI-gerelateerde code te bevatten en de andere om middleware-code te bevatten. De teams worden dienovereenkomstig toegewezen.
Ga naar het Opslagplaatsen tab en maak een Nieuwe repository
Klik op de Maak een opslagplaats knop. De volgende is om UI Team-toegang tot de repository te geven.
Ga naar het Teams tabblad. Klik op de UI Team en ga naar het Opslagplaatsen tabblad. Klik op elk team en voeg de repositories opnieuw toe vanuit het Opslagplaatsen tabblad.
Voeg de repository toe door de naam van de repository in te voeren.
Zorg er ook voor Schrijf toestemming voor de teamleden naar deze repository, d.w.z. de teamleden kunnen deze repository lezen, klonen en pushen.
Voer op dezelfde manier de bovenstaande stappen uit om de middleware-repository aan het andere team toe te voegen. Zo hebben we nu een organisatie met daarin repositories en ook de teams. De teamleden kunnen de repository klonen waartoe ze toegang hebben en eraan werken.
GitHub Fork
Fork een repository en blijf gesynchroniseerd met de originele repository.
In de vorige secties en de vorige tutorial zagen we dat er repositories werden gemaakt en broncode eraan werd toegevoegd. Nu, wat als de teams enkele codewijzigingen willen testen terwijl de oorspronkelijke repository niet de plek is om het te doen?
Er moet een kopie worden gemaakt om te experimenteren met eventuele wijzigingen in de code door de originele repository intact te houden. Dit heet GitHub Vork Om een Fork te maken, navigeert u naar de opslagplaats die is gemaakt in het persoonlijke account en niet de organisatie. Klik op Vork op de rechterbovenhoek.
Selecteer het account waar u de originele repository moet splitsen. Selecteer in dit geval het organisatieaccount waar de repository wordt gevorkt.
De repository is nu gevorkt als Demo-Proj-Org / Demo_Project_Repo_VN Alle experimenten met de code kunnen dus worden uitgevoerd in de gevorkte opslagplaats en niet in de oorspronkelijke opslagplaats.
Als er wijzigingen zijn aangebracht in de oorspronkelijke repository, moet de gevorkte repository zich in synchroniseren Opdrachtregelopties kunnen worden gebruikt om de gevorkte repository gesynchroniseerd te krijgen, maar het maken van een pull-verzoek is een eenvoudigere optie.
Ervan uitgaande dat er een wijziging is aangebracht in een bestand in de oorspronkelijke repository, gaat u verder met het maken van een Pull Request.
Klik op de link vergelijk over vorken.
Selecteer het hoofd als de originele repository en de basis als de gevorkte repository, zoals weergegeven en klik op Maak een pull-verzoek.
Klik op Samenvoegen pull-aanvraag en bevestig de samenvoeging.
De wijzigingen verschijnen in de gevorkte repository en zijn gesynchroniseerd met de originele repository.
GitHub-problemen en projectmijlpalen
Normaal gesproken moet men in elk project taken, defecten, verbeteringen, enz. Volgen als onderdeel van de voortgang. U kunt de problemen in GitHub gebruiken om alle bovengenoemde problemen bij te houden, samen met de projectborden.
Bij problemen kunt u hetzelfde aan pull-verzoeken koppelen, zodat het automatisch kan worden gesloten wanneer het pull-verzoek wordt samengevoegd. Als er openstaande problemen zijn, kunnen deze ook naar andere opslagplaatsen worden overgebracht. In dit gedeelte zullen we veel meer zien over hoe problemen kunnen worden gebruikt.
Problemen en mijlpalen creëren
Ga naar de hoofdpagina van de repository en ga naar het Problemen Tab. Klik op Nieuw probleem.
Wijs het toe aan een medewerker om aan te werken, voeg Label toe om te onderscheiden als een verbetering. Een goede gewoonte is ook te vermelden over de Mijlpaal om de voortgang van de aangekaarte problemen te volgen.
Klik op Dien een nieuw probleem in.
Het probleemoverzicht wordt weergegeven. Merk op dat het uitgiftienummer # 11 is, waarnaar later zal worden verwezen.
Het probleem kan ook naar een andere opslagplaats worden overgebracht. De optie om dit te doen staat onderaan ‘Overdrachtsprobleem’.
Voeg een ... toe opleveringsdatum naar de mijlpaal - R1. Ga op de hoofdpagina van de repository naar het Problemen Tab en klik op Mijlpalen
Bewerk de details voor de Milestone R1 en voeg een vervaldatum toe. Sla de aangebrachte wijzigingen op.
De Milestone R1 heeft nu 2 openstaande issues en het% van voltooiing is ook te zien.
Klik op de mijlpaal R1 om de problemen te bekijken die voor deze mijlpaal moeten worden geleverd. Issues kunnen ook opnieuw geprioriteerd worden door de issues op en neer te bewegen.
Filterproblemen
Ervan uitgaande dat er meerdere problemen zijn die zich in de status Openen / Sluiten bevinden en zijn toegewezen aan meerdere medewerkers. Het is zeer essentieel om te zoeken naar die kwesties die op bepaalde criteria zijn gebaseerd.
Bijvoorbeeld, alle issues die aan jou zijn toegewezen, alle issues in open staat, etc. GitHub biedt de zoekoptie om te filteren op de issues en zelfs pull-verzoeken.
Ga naar het tabblad Problemen en voer in het filtervak de criteria als volgt in.
Bijvoorbeeld alle openstaande issues in de status Open en toegewezen aan een medewerker.
beste schijfopruiming voor Windows 10
type: issue state: open toegewezen: vniranjan2512 mijlpaal: R1 label: enhancement
Koppel problemen aan Pull Request
Wanneer naar een Pull Request wordt verwezen met een bepaald trefwoord & issue nummer en eenmaal samengevoegd, wordt de issue automatisch gesloten. Zelfs als naar een vastlegging wordt verwezen met trefwoord en probleemnummer, is het probleem gesloten.
Het trefwoord kan elk zijn, d.w.z. sluiten, sluiten, repareren, repareren, oplossen, oplossen.
Bijvoorbeeld, in het pull request of commit bericht vermelden sluit # 11.
Maak een pull-aanvraag en vermeld het trefwoord en het referentienummer zoals weergegeven in het bericht. Klik op Maak een pull-aanvraag en voeg samen.
Het probleem wordt automatisch gesloten bij het samenvoegen van het pull-verzoek. Een beetje automatisering is absoluut nodig.
Maak of open nieuwe problemen vanuit de broncode
Voor elke codewijziging kan een nieuw nummer worden geopend. Hiermee wordt de URL naar de regel met codewijziging toegevoegd aan het probleem. In een niet-bewerkingsmodus van de code klikt u op de 3 puntjes (…) naast de coderegel en selecteert u Referentie in nieuwe uitgave
Probleemdetails bijgewerkt.
Pin probleem
U kunt het probleem vastzetten zodat het gemakkelijker wordt om de problemen op te sporen en ook dubbele problemen van gecreëerd worden.
Open de uitgave en klik rechtsonder in de uitgave op Pin probleem.
Het probleem is nu toegevoegd boven de lijst met problemen.
Opmerking: Er kunnen maximaal 3 nummers tegelijk worden vastgezet.
GitHub-projectbord
Een projectbord in GitHub biedt een gemakkelijke manier om de problemen te visualiseren. U kunt de voortgang van het project bekijken en kijken welke problemen nog moeten worden gestart, lopende en afgeronde problemen.
Een projectbord in GitHub kan worden gemaakt op basis van Kanban-sjablonen die een vooraf gedefinieerde workflow hebben en ook kunnen worden aangepast. Het voorbeeld toont een bord dat is gemaakt op basis van het gebruikersaccount.
Ga op de hoofdpagina van de repository naar het Projecten tab en maak een Nieuw project.
Zoals je van bovenaf kunt zien, helpt het projectbord om:
- Sorteer taken
- Plan uw project
- Automatiseer uw workflow
- Volg de voortgang
- Deel status
- Sluit project
Nieuw projectbord met een basis Kanban-sjabloon.
Het bord is gemaakt met een workflow. Extra workflowkolommen kunnen ook worden toegevoegd door op het + Kolom toevoegen.
De workflow kan ook worden geautomatiseerd. Bijvoorbeeld, als er een nieuwe uitgave wordt aangemaakt, kan deze direct worden toegevoegd aan het To-Do-status. Selecteer de Beheer automatisering optie voor die status.
Schakel het selectievakje in Nieuw toegevoegd en klik op Automatisering bijwerken. Dus als er een nieuw nummer wordt aangemaakt, wordt het project dat voor het nummer is geselecteerd automatisch toegevoegd aan het To-Do-status. U kunt het bestaande probleem ook slepen en neerzetten in de status en van de ene status naar de andere gaan.
Aan een kolom kunt u ook opmerkingen toevoegen die ervoor zorgen dat u belangrijke informatie over de problemen in die kolom verstrekt. Klik op de teken en voeg een notitie toe.
Klik op Toevoegen.
GitHub Wiki voor documentatie
Een van de zeer belangrijke activiteiten in elk project is het maken en onderhouden van documentatie voor uw repository zodat het hele team deze kan gebruiken. De GitHub-repository wordt geleverd met ondersteuning voor het maken van dergelijke documentatie met behulp van GitHub Wiki. Dus alle informatie over uw project en het gebruik ervan kan in de wiki worden vastgelegd.
Wiki's zijn gratis beschikbaar voor openbare repositories in GitHub. Wiki's gebruiken Open source Markup-bibliotheek. We zullen zien hoe we deze bibliotheek kunnen gebruiken tijdens het schrijven van wiki's.
Wiki-ondersteuning voor repository inschakelen
Klik op de hoofdpagina van de repository op het Instellingen tabblad en zorg ervoor dat het Wiki's optie is geselecteerd onder de Kenmerken sectie.
Maak een GitHub Wiki
Ga op de hoofdpagina van de repository naar het Wiki tabblad. Klik op Maak de eerste pagina.
Voer een titel in en voeg tekst toe aan de Wiki. U kunt ook de opmaakoptie gebruiken met Markdown-ondersteuning. Klik op de Sla pagina op eenmaal gedaan.
Merk op dat in de bovenstaande inhoud # is voor kop1, ## is voor kop2, ### is voor kop3. * wordt gebruikt voor ongeordende lijsten. Het voorbeeld is zoals hieronder weergegeven.
welke vr-headsets werken met ps4
Op de Wiki tab klik op + Voeg een aangepaste voettekst toe.
Voeg de inhoud toe en sla de pagina op.
Open een opgeslagen Wiki en je ziet de voettekst.
Voeg zijbalk toe
Klik op het tabblad wiki op + Voeg een aangepaste zijbalk toe.
Voeg inhoud toe voor de zijbalk en sla de pagina op.
Open een wiki en je ziet de zijbalk.
Bekijk de Wiki-geschiedenis
In de geschiedenis kunt u zien wie de wijziging heeft aangebracht, berichten vastleggen en de datum waarop de wijziging is aangebracht.
Open Wiki en bewerk de pagina. Klik op Paginageschiedenis, aan de rechterkant.
Klik op Hash om de wijzigingen te bekijken. Selecteer de revisies om wijzigingen te vergelijken en wijzigingen van een nieuwere revisie ongedaan te maken. Klik op Wijzigingen terugdraaien.
De wijzigingen worden teruggezet naar de oudere revisie.
Notitie : U kunt de wijzigingen ongedaan maken op basis van de toestemming om de Wiki te bewerken.
Gevolgtrekking
In deel 1 en deel 2 van de GitHub-serie hebben we gezien over versiebeheeractiviteiten, opslagplaatsen maken, pull-verzoeken, branches, codebeoordelingen, organisaties en teams, fork a repository, labels, mijlpalen, problemen, github-projecten, wiki's.
In onze aanstaande tutorial zullen we kijken naar het maken van releases, integratie met Jira en enkele Git-opdrachten dat zal ontwikkelaars helpen voordat ze wijzigingen naar de GitHub-repository pushen.
We hopen dat alle ontwikkelaars deze praktische benadering voor GitHub nuttig zullen vinden in hun projecten.
Bezoek hier voor de exclusieve GitHub Training Tutorial Series.
Aanbevolen literatuur
- Soorten risico's in softwareprojecten
- GitHub-zelfstudie voor ontwikkelaars | Hoe GitHub te gebruiken
- Hoe Microsoft TFS te gebruiken voor JAVA-projecten met Eclipse in DevOps
- JIRA Agile-zelfstudie: JIRA effectief gebruiken voor het beheren van Agile-projecten
- Hoe verschilt de testplanning voor handmatige en automatiseringsprojecten?
- Voorbeelden van seleniumbeweringen - praktische toepassingen in projecten
- Onsite - Offshore-model van softwaretestprojecten (en hoe u dit voor u kunt laten werken)
- Git vs GitHub: ontdek de verschillen met voorbeelden