github tutorial developers how use github
Deze GitHub-zelfstudie legt uit wat GitHub is en hoe je een repository, branch & pull-aanvraag kunt maken. Het omvat Branch Protection Rules & Conflict Resolution:
Wat is GitHub?
GitHub is een cloudservice die ontwikkelaars helpt hun broncode op te slaan en te beheren en alle wijzigingen in de broncode bij te houden en te beheren.
In eenvoudige bewoordingen is GitHub bedoeld voor ontwikkelaars waarbij ze het project kunnen beheren, de broncode kunnen hosten en deze ook kunnen beoordelen. We zullen deze allemaal in deze serie onderzoeken.
Lijst met tutorials in deze GitHub-serie:
Tutorial # 1: GitHub-zelfstudie voor ontwikkelaars | Hoe GitHub te gebruiken (Deze tutorial)
Tutorial # 2: GitHub Projects, Teams, Fork & Wiki voor het documenteren van projecten
Tutorial # 3: Geavanceerde Git-opdrachten en GitHub-integratiehandleiding
Tutorial # 4: GitHub REST API-zelfstudie - REST API-ondersteuning in GitHub
Tutorial # 5: GitHub Desktop-zelfstudie - Werk samen met GitHub vanaf uw desktop
Tutorial # 6: TortoiseGit Tutorial - Hoe TortoiseGit te gebruiken voor versiebeheer
Wat je leert:
Wat is Git?
Git is een Open Source-versiebeheersysteem waarbij de volledige broncode beschikbaar is op de computer van de ontwikkelaar. Git is ook een Client and Distributed Version Control System (DVCS) waar je kunt vertakken en samenvoegen.
Aan de slag met GitHub
Om aan de slag te gaan met GitHub, zullen we de volgende stappen uitvoeren.
- Maak een repository om projecten te organiseren.
- Maak een filiaal
- Breng wijzigingen aan in het bestand en leg vast.
- Maak een Pull Request om inhoud samen te voegen.
- Bescherm Branch
In het tweede deel van de serie zullen we ook kijken naar de andere features van GitHub zoals Creating Organization, Teams, Issues, Milestones, Forks, Releases en Wikis.
Maak een GitHub-repository
Een GitHub-repository bevat de artefacten van het project, zoals broncode, documenten, afbeeldingen, enz. We zullen een demo-repository maken en gebruiken om alle bovenstaande stappen uit te voeren.
Log in op Github.com en Maak een nieuwe opslagplaats Klik op de Nieuw knop.
Voeg de onderstaande repo-details toe zoals weergegeven en klik op Maak een opslagplaats Stel de toegang in op Privé of Openbaar. Het is beter om het openbaar te maken, aangezien er maar weinig functies afhankelijk zijn van deze toegang.
Opmerking: de gebruiker die de repository maakt, is de eigenaar van de GitHub Repository.
De repository wordt gemaakt met een README-bestand.
Bijdragers toevoegen aan de GitHub-opslagplaats
We zouden willen dat het team aan deze repository werkt. Hiervoor zullen we de medewerkers moeten uitnodigen om aan de repository te werken. Om bijdragers toe te voegen, gaat u naar de hoofdpagina van de Repository en klikt u op het Instellingen icoon.
Klik op Medewerkers in het linkerdeelvenster en voeg de bijdragers toe die een Github-account hebben. Er wordt een uitnodiging verzonden en de bijdragers moeten de uitnodiging accepteren.
Medewerkers worden toegevoegd zoals hieronder weergegeven. Later, in deze tutorial, zullen we zien hoe de bijdragers zullen worden toegevoegd als de reviewer voor het pull-verzoek dat is gemaakt om de code samen te voegen.
Een basis C uitvoeren weglaten
Open het README-bestand en voer een basiscommit uit. Klik op de Pictogram bewerken om het bestand te wijzigen.
Pas het bestand aan, voeg een opmerking toe en klik op Commit
Het bestand is vastgelegd (wijzigingen opgeslagen) naar de Github-repository.
Er zijn maar weinig bewerkingen om mappen en bestanden in de repository te maken.
Om de map en een bestand te maken binnen: Klik op de Maak een nieuw bestand knop op het Repository-niveau. Typ de naam van de directory gevolgd door / en de naam van het bestand zoals hieronder weergegeven.
Klik op Commit aan de onderkant. De map en het bestand worden gemaakt zoals weergegeven. De bestanden en mappen worden dus gemaakt op het meester branch die de belangrijkste integratietak is en waar de softwareversies meestal kunnen worden gebouwd.
De ontwikkelaars werken normaal aan de taak die aan hen is toegewezen op een aparte branch en voegen de wijzigingen samen in de master branch. Bijvoorbeeld, branches kunnen aangemaakt worden voor het ontwikkelen van features of het oplossen van bugs of het werken aan verbeteringen, etc. Dus door een branch te creëren wordt het werk geïsoleerd zonder de andere branches te storen.
In de volgende stap kunnen we kijken hoe de branches kunnen worden gemaakt en pull-verzoeken kunnen worden gedefinieerd om de code te herzien en samen te voegen in de master branch.
Een bestand verplaatsen
Voer de volgende stappen uit om een bestand naar een andere map te verplaatsen. Bijvoorbeeld, om het bestand rules.txt naar een doc-map te verplaatsen. Klik op het bestand.
Klik op het icoon om het bestand te bewerken.
Voeg het pad toe doc / voor het bestand rules.txt Klik op Veranderingen doorvoeren.
Het pad is nu bijgewerkt.
Een GitHub-vertakking maken
Ga naar de hoofdpagina van de repository en typ om een voorzien zijn van tak zoals afgebeeld. Klik op Maak een filiaal.
We zijn nu in de voorzien zijn van Afdeling. De bestanden zijn hetzelfde. We zullen nu enkele wijzigingen aanbrengen in de bestanden in het voorzien zijn van branch en maak een pull-verzoek om de wijzigingen te bekijken en de code samen te voegen in het meester Afdeling.
Breng wijzigingen aan in de bestanden in de feature branch.
Open het Java-bestand in de Src-map en voeg wat code toe en voer de wijziging uit.
Maak een GitHub Pull Request
In de vorige sectie hebben we een branch gemaakt voorzien zijn van en bracht enkele wijzigingen aan in een bestand. De wijzigingen staan niet in de meester Afdeling. Hiervoor moeten we een Pull Request maken waarmee de gebruiker bepaalde wijzigingen voorstelt om te bekijken en samen te voegen met het meester Afdeling.
Het aanmaken van Pull Request zal de verschillen tussen de source en target branch laten zien en zal nodig zijn om eventuele conflicten op te lossen.
Klik op Compare & Pull Request op de hoofdpagina van de repository.
U kunt zien dat de wijzigingen over beide takken kunnen worden samengevoegd. Klik op Maak een Pull Request.
Klik op Pull Request samenvoegen en Bevestigen om de samenvoeging te voltooien.
Wijzigingen zijn met succes samengevoegd in het meester Afdeling. Ons eerste Pull-verzoek is met succes voltooid.
Wijs recensenten toe met pull-verzoeken en codebeoordeling
Github heeft een goede eigenschap om een CODEOWNERS-bestand te gebruiken waarin we de mensen kunnen selecteren die verantwoordelijk zijn voor de broncode in de repository. Repository-eigenaren kunnen dit bestand maken en alle gebruikers die in het bestand zijn gedefinieerd, worden standaard aangevraagd voor de beoordeling tijdens het maken van een pull-aanvraag.
Om deze functie te gebruiken, moet u de GitHub Pro-versie gebruiken of de repository openbaar maken.
Maak dit bestand in de root van de repository aan in de volgende indeling en leg het vast.
* @gebruikersnaam of @orgnaam of @teamnaam
betekent primair alle bestanden in de repo. U kunt ook specifieke extensies specificeren zoals * .java of * .js enz. De gebruikers die in het bestand zijn gedefinieerd, zullen automatisch een verzoek om beoordeling ontvangen. Als het CODEOWNERS-bestand is gedefinieerd, is het niet nodig om recensenten expliciet handmatig toe te voegen en heeft het een beetje meer flexibiliteit om te kiezen welke bestanden moeten worden beoordeeld.
Terug in de voorzien zijn van branch breng een kleine wijziging aan in het Java-bestand en maak een Pull Request. Wijs in het Pull Request-scherm een reviewer aan de rechterkant toe. Klik op Maak een Pull Request.
U kunt in het bovenstaande scherm zien dat de reviewers handmatig kunnen worden toegewezen, maar de reviewers worden gedefinieerd in het CODEOWNERS-bestand en krijgen automatisch een verzoek om de codewijzigingen te bekijken.
Hoe dan ook, voor nu, laten we Log in als reviewer en keur de wijzigingen goed. Log in als de gebruiker vniranjan2512 om de wijzigingen goed te keuren.
Er is een verzoek om de wijzigingen goed te keuren / af te wijzen, onder Pull-verzoek.
Klik op het Pull Request en Voeg uw recensie toe.
U kunt op het teken en voeg recensieopmerkingen toe voor de regel code Toegevoegd / Gewijzigd / Verwijderd, op het scherm dat verschijnt.
Klik op Start een beoordeling.
Klik op Maak je recensie af. Goedkeuren zoals weergegeven en Review versturen
Terug als de oorspronkelijke gebruiker die een pull-verzoek heeft ingediend, kunt u een opmerking toevoegen en het gesprek oplossen of sluiten.
Het pull-verzoek voor samenvoegen kan nu worden voltooid.
De wijzigingen zijn met succes samengevoegd in het meester branch post de beoordeling en het samenvoegen van het pull-verzoek.
Om in dit stadium samen te vatten, hebben we gezien dat ontwikkelaars werken aan het voorzien zijn van branch en verhoog vervolgens een Pull Request om de wijzigingen in het meester Afdeling. Het bovenstaande was een scenario waarin er geen conflicten waren. In de volgende sectie zullen we de manieren zien om conflicten handmatig op te lossen als de bestanden in meerdere branches worden gewijzigd.
Conflicten oplossen
Het is mogelijk dat dezelfde bestanden in meerdere branches worden gewijzigd. In dit geval zouden er conflicten zijn en deze moeten worden opgelost via het opgehaalde Pull Request.
Bijvoorbeeld, breng wijzigingen aan in het Java-bestand in zowel de meester en voorzien zijn van takken en een pull-verzoek indienen.
Het pull request-bericht dat wordt weergegeven, is dat de wijzigingen niet automatisch kunnen worden samengevoegd. Daarom moeten de conflicten worden opgelost. Ga verder met het maken van een Pull Request.
Zodra het pull-verzoek is ingediend, moeten de conflicten worden opgelost door op het Conflicten oplossen knop.
Verwijder de markeringen die in wezen handmatig conflicten oplossen en klik op Markeer als opgelost en Commit samenvoegen.
De uiteindelijke weergave van het bestand nadat de markeringen zijn verwijderd.
Pull-verzoek samenvoegen kan worden voltooid. De meester en voorzien zijn van branches zullen nu identiek zijn.
U kunt in het bovenstaande scherm nog steeds zien dat de beoordeling is aangevraagd maar niet verplicht. In de volgende sectie zullen we zien over de branchebeschermingsregels waarin de eigenaar van de repository verplicht kan verzoeken om een beoordeling en ook de meester branch van rechtstreeks committeren, maar alleen via een pull-verzoek.
Regels voor filiaalbescherming
In de vorige secties zagen we over Github Pull Requests en ook vragen om beoordelingen die niet verplicht of optioneel waren. In typische code voor projectscenario's zijn de beoordelingen een must en een onderdeel van het ontwikkelingsproces.
Laten we eens kijken hoe we dit kunnen afdwingen.
In github.com kan deze functie alleen worden ingesteld voor openbare repositories of met de Github pro-versie. Ga op de hoofdpagina van de Repository naar Instellingen en klik op het Takken categorie aan de linkerkant.
Klik op Regel toevoegen onder de Regels voor bijkantoorbescherming. De regel voegde verzoeken toe voor verplichte beoordelingen van pull-aanvragen van de code-eigenaren voordat ze werden samengevoegd voor het meester Afdeling.
Dit zorgt er ook voor dat het master branch is beschermd en er kunnen geen directe commits worden gedaan op deze branch en kunnen alleen worden vastgelegd via de Pull Requests na een grondige beoordeling. Deze instelling wordt bepaald door de eigenaar van de repository.
Een geweldige functie inderdaad !!!
Klik op Creëer eenmaal gedaan. Om dit scenario te testen, brengt u een wijziging aan in een bestand in het voorzien zijn van branch en maak een pull-verzoek.
Het volgende scherm laat zien dat een review verplicht is door de code-eigenaren.
Plaats de recensie van de code-eigenaren, het pull-verzoek kan worden samengevoegd.
Als een medewerker van de repository, als je wijzigingen aanbrengt in een van de bestanden, als gevolg van de aangemaakte regels van de beschermde branches, zul je niet in staat zijn om rechtstreeks vast te leggen op de master branch, maar alleen via een Pull Request nadat je een branch hebt aangemaakt zoals getoond hieronder.
Een opslagplaats overbrengen naar een andere gebruikersaccount
Normaal gesproken heeft een persoonlijke gebruikersrepository één eigenaar en zijn alle anderen bijdragers. Dus in zekere zin kunt u niet meerdere eigenaren hebben in de opslagplaats van een gebruikersaccount. Maar het eigendom kan worden overgedragen naar een ander gebruikersaccount. Als dit klaar is, wordt de oorspronkelijke eigenaar van de repository automatisch medewerkers in de nieuwe repository van gebruikersaccounts.
De nieuwe eigenaar kan dan beginnen met het beheren van de artefacten, problemen, pull-aanvragen, projecten, releases en instellingen.
Normaal gesproken zullen commando's zoals ‘git clone’ of ‘git push’ worden uitgevoerd in de lokale repository, de commando's omleiden naar de nieuwe repository. Maar als je het ‘git remote -v’ commando uitvoert, zal het nog steeds de originele repository URL tonen. Om verwarring te voorkomen bij het wijzigen naar de nieuwe externe URL, plaatst u de overdracht van de repository met de opdracht ‘git remote set-url’.
Om een repository over te zetten, gaat u naar het tabblad Instellingen van de repository en onder Opties? Danger Zone klik op Overdracht
Voer de naam van de repository in en het nieuwe gebruikersaccount waaraan het eigendom moet worden overgedragen.
Klik op Ik begrijp het, draag deze repository over
U zou een bericht moeten zien dat de repository is overgedragen aan de nieuwe eigenaar.
Er wordt een e-mail gestuurd naar de oorspronkelijke eigenaar van de repository om de overdracht goed te keuren. Zodra de overdracht is goedgekeurd, wordt de repository overgedragen aan de nieuwe eigenaar en wordt de oorspronkelijke eigenaar van de repository toegevoegd als medewerker.
Stel nu de nieuwe repository-URL in op de machine waarop de oude repository is gekloond. De volgende commando's moeten worden ingesteld op alle machines waarop de oude repository is gekloond.
Alle pull-verzoeken, problemen en wiki worden overgedragen. Uitgiftetoewijzingen blijven intact.
Enkele nuttige Git-opdrachten
Er zijn enkele van de basis Git-commando's die in eerste instantie op je lokale computer moeten worden geconfigureerd zodra de Git-client op je Linux- of Windows-computer is geïnstalleerd. Ontwikkelaars werken lokaal, zonder verbinding met de repository op GitHub, aan de volledige kopie van de broncode die beschikbaar is op GitHub en synchroniseren ermee.
Stel eerst uw gebruikersnaam en e-mailadres in om ervoor te zorgen dat alle commits die u doet deze informatie gebruiken.
git config –global user.name “Gebruikersnaam”
git config –global user.email “myemail@myemail.com”
Als je een bericht moet toevoegen tijdens commits, kun je ook de editor configureren die hiervoor nodig is.
wat je ziet, is wat je website builder krijgt
git config –global core.editor kladblok
Krijg een lijst met alle ingestelde configuratiewaarden.
git config –list
Soms hebben organisaties proxyservers om verbinding te maken met internet. In dat geval moet u een proxyserver en poortnummer specificeren om toegang te krijgen tot alle repositories op GitHub.
git config –global http.proxyhttp: // Gebruikersnaam: Wachtwoord @ proxyserver: poort
Kloon of maak een lokale kopie van de repository. Haal de kloon-URL van de repository op in GitHub en voer het git-commando uit.
Gevolgtrekking
In deze tutorial hebben we gezien hoe een ontwikkelaar aan GitHub kan gaan werken, direct vanaf het maken van een GitHub-repository, Branch, Pull Request, het beschermen van een branch en enkele basis Git-commando's.
In onze aanstaande tutorial zullen we de andere functies van GitHub zien, voornamelijk over het maken van organisaties, teams, het maken van een repository, het creëren van problemen, mijlpalen en het associëren met pull-verzoeken, wiki's en hun gebruik en enkele andere geavanceerde Git-commando's die nuttig zullen zijn aan de ontwikkelaars.
Aanbevolen literatuur
- Zelfstudie over reflectie in Java met voorbeelden
- Git vs GitHub: ontdek de verschillen met voorbeelden
- Python DateTime-zelfstudie met voorbeelden
- Selenium-integratie met GitHub met behulp van Eclipse
- Een snelle SoapUI-gids om verzoek- en reactiegegevens in een bestand op te slaan - SoapUI-zelfstudie # 15
- Bugzilla-zelfstudie: Praktische zelfstudie voor hulpprogramma voor defectbeheer
- 20+ MongoDB-zelfstudie voor beginners: gratis MongoDB-cursus
- MongoDB Sharding-zelfstudie met voorbeeld