Geavanceerde Git-opdrachten en GitHub-integratiehandleiding

advanced git commands

Deze tutorial onderzoekt nuttige Git-opdrachten zoals Git Stash, Git Reset, Git Cherry Pick, Git Bisect en legt uit hoe je GitHub kunt integreren met Jira:

In onze vorige tutorials in deze serie hebben we de meeste functies van GitHub gezien.

In deze tutorial kijken we naar het volgende:

• Releases maken
• Integratie met Atlassian Jira
• Meest gebruikte Git-commando's voor ontwikkelaars
  • Git Stash
  • Git Cherry Pick
  • Git Reset
  • Git Bisect

​ Bekijk hier de GitHub-gids.

hoe je een volledige afspeellijst van youtube kunt downloaden zonder software

Wat je leert:

• Releases maken
• GitHub-integratie met Jira
  • GitHub Commit met Jira Issue
  • Maak een filiaal
• Geavanceerde Git-opdrachten voor ontwikkelaars
  • Git Stash
  • Git Cherry Pick
  • Git Reset
  • Git Bisect
• Gevolgtrekking
• Aanbevolen literatuur

Releases maken

Releases in GitHub worden gebruikt om uw software te bundelen, release-opmerkingen en binaire bestanden (WAR-, EAR-, JAR-bestanden) toe te voegen zodat klanten en mensen deze kunnen gebruiken.

Om een ​​release aan te maken, gaat u naar de hoofdpagina van de repository en klikt u op het Releases tabblad onder Beheer onderwerpen.

Klik op Maak een nieuwe release.

Geef een tag en een releasetitel op. De binaire bestanden zijn ook aan de release toegevoegd. Als u klaar bent, klikt u op Publiceer release.

De release is nu klaar met de broncode en binaire bestanden.

GitHub-integratie met Jira

Een van de belangrijke traceerbaarheidsaspecten is om te verwijzen naar het Jira-probleem met de commits in GitHub. GitHub kan met Jira worden geïntegreerd, niet alleen om naar het probleem te verwijzen, maar ook om te helpen bij het maken van branches en Pull Request vanuit Jira.

Dus typisch, zodra de ontwikkelaar begint te werken aan de taak of bugs, wordt door hem een ​​branch aangemaakt. Plaats de ontwikkeling of los de bugs op, een pull-verzoek kan vanuit Jira worden gemaakt om samen te voegen met het hoofdbestand meester Afdeling. De door de ontwikkelaar aangemaakte branch kan vervolgens worden verwijderd.

Om de integratie op te zetten hebben we een plugin gebruikt Git-integratie voor Jira. Dit is een commerciële plug-in. De plug-in kan worden gedownload van hier

Installeer de plug-in in Jira van Admin -> Add-ons.

Zodra de plug-in is geïnstalleerd, gaat u naar Toepassing -> Git-opslagplaatsen en maak verbinding met GitHub.

Voer de gebruikersnaam en het wachtwoord van GitHub in. Klik Aansluiten ​

De opslagplaatsen die voor het gebruikersaccount worden genoemd, worden weergegeven. Klik op Importeer opslagplaatsen om de integratie-instellingen te voltooien.

GitHub Commit met Jira Issue

Voer als onderdeel van het vastlegbericht in zoals hieronder wordt getoond. Klik op Veranderingen doorvoeren ​

Voorbeeld 1: Hieronder ziet u een voorbeeld van Slimme toewijding waarmee de ontwikkelaars acties kunnen uitvoeren op de Jira-problemen vanuit het vastlegbericht. Een voorbeeld van zo'n commando is het #commentaar samen met de Issue-sleutel die de opmerking toevoegt aan het Jira-probleem, zoals hieronder wordt weergegeven.

Reactiessectie bijgewerkt.

Voorbeeld 2: Wijs toe aan een gebruiker en update de bestede tijd als 4 uur.

Gebruik de #toewijzen en #tijd smart commit commando in het commit bericht.

Beide acties zijn voltooid.

Voorbeeld 3: Wijzig de status van het probleem in Bezig ​

Maak een filiaal

Omdat taken en bugs aan ontwikkelaars worden toegewezen, moeten ze aan de ontwikkeling gaan werken. Hiervoor maken ze een branch aan voor het issue waar ze aan werken, doen de ontwikkelingsactiviteiten en doen een pull request om samen te voegen met de master branch.

Klik in het Jira-nummer onderaan op Maak een filiaal.

Klik op Maak een filiaal.

Breng in GitHub een wijziging aan in het bestand in de hierboven gemaakte branch en voer hetzelfde uit.

Als de ontwikkeling is voltooid, kan de gebruiker een Pull Request van Jira indienen.

Klik onderaan het nummer op Maak een Pull Request.

Klik op Creëer. Het Pull Request wordt weergegeven als Open.

De volgende stap is om het pull-verzoek samen te voegen in GitHub.

De status wordt dienovereenkomstig bijgewerkt in Jira.

Geavanceerde Git-opdrachten voor ontwikkelaars

In deze laatste sectie zullen we enkele van de veelgebruikte Git-commando's voor ontwikkelaars bekijken. Niets te maken met GitHub, maar zal de ontwikkelaars helpen voordat ze de wijzigingen naar GitHub pushen.

Git Stash

In de meeste projectscenario's, wanneer u aan een nieuwe functie of verbetering werkt, moet u plotseling aan een urgent defect werken dat is gemeld en een showstopper is. Aangezien u halverwege uw nieuwe werk bent en het nog niet heeft voltooid, heeft het geen zin om de veranderingen die voor de helft zijn voltooid, te maken.

Het is dus beter om het halfafgemaakte werk tijdelijk op te schorten of op te slaan, aan de bug te werken en weer aan de nieuwe functie of verbetering te werken. Git stash biedt hier een oplossing voor. U kunt eenvoudig de context wijzigen om snel wijzigingen aan te brengen.

voorbeeld 1 ​Stel dat u werkt aan een taak die aan u is toegewezen en als u naar de status kijkt, laat dit zien dat deze vanaf nu niet is gevolgd.

Plots wordt er een bug met hoge prioriteit aan u toegewezen. Daarom moeten we het werk waaraan momenteel wordt gewerkt, tijdelijk opslaan of opbergen.

Voer de volgende opdracht uit.

git stash save 'Bericht'

Op dit moment is de werkdirectory schoon. Elke nieuwe commits kan worden gemaakt en als er bugs zijn, kun je van branch wisselen om eraan te werken enz.

Gebruik de opdracht als u de wijzigingen opnieuw wilt toepassen waar u was gebleven.

git stash pop

De bovenstaande opdracht verwijdert de stash uit de lijst en past de laatst opgeslagen status toe.

Je kan ook gebruiken:

git stash toepassen

Met het bovenstaande commando worden de wijzigingen in de stash bewaard en niet verwijderd.

Nu worden de wijzigingen opnieuw toegepast en kunt u de wijzigingen vastleggen.

Voorbeeld 2: Bewaar uw wijzigingen, wissel van branch en voeg wijzigingen samen.

Breng de wijziging aan in het html-bestand in het meester branch en stash veranderingen.

De volgende is om over te schakelen naar het bug branch, breng wijzigingen aan en voer wijzigingen door.

git checkout -b bug

Breng wijzigingen aan in het html-bestand.

git commit -a -m 'Probleem met e-mail opgelost'

Schakel terug naar de meester branch en pas wijzigingen van stash opnieuw toe.

Voeg nu samen vanuit het bug aftakking naar de meester Afdeling. Leg de wijzigingen vast na het samenvoegen.

Voorbeeld 3: Werken met Multiple Stash.

In de lokale opslagplaats zijn er 2 html-bestanden. Het is dus mogelijk dat meerdere ontwikkelaars aan meerdere bestanden werken en wijzigingen opslaan als dat nodig is om te werken aan dringende verzoeken die op hun pad komen om de wijzigingen op te lossen.

Developer 1 werkt op hello.html en Developer 2 werkt op index.html.

Ontwikkelaar 1

De voorraadlijst heeft nu 1 item.

Ontwikkelaar 2

De opberglijst heeft nu 2 items. De nieuwste stash staat als eerste in de stapel, stash @ {0}. Nu kunnen beide ontwikkelaars dringend andere commits doen of aan een andere branch werken en dan terugkeren naar het meester branch en pas de stashwijzigingen toe.

Om de nieuwste stash toe te passen, kun je gewoon rennen

git stash pop

Om een ​​specifieke stash in de stack toe te passen, voert u de volgende opdracht uit.

git stash pop stash @ {1}

Laten we de tweede voorraad toepassen, namelijk stash @ {1}

Evenzo kan de andere voorraad worden aangebracht.

Git Cherry Pick

Tegenwoordig werken de ontwikkelaars aan meerdere branches zoals feature, enhancement, bug, etc.

Er zijn situaties waarin slechts een paar specifieke commits moeten worden gekozen en niet de hele branch in een andere branch moet worden samengevoegd. Dit heet een Cherry Pick. Dit proces staat je toe om willekeurig welke Git-commit uit de andere branches te kiezen en deze toe te voegen aan de huidige HEAD van de werkende boom.

Voorbeeld 1:

In de lokale git-repository hebben we de volgende 6 bestanden.

Eén bestand is verwijderd, bijvoorbeeld file5.txt.

Leg de wijzigingen vast.

Kijk nu naar het logboek. File5.txt is verwijderd.

Dus we willen Cherry-Pick de commit waar we file5.txt hebben toegevoegd. We moeten de commit-id van file5.tx vinden en de opdracht uitvoeren.

git cherry-pick

In dit geval is de commit-id van wanneer file5.txt werd toegevoegd a2f0124

File5.txt is nu hersteld. We hebben Cherry-Picked de commit.

Voorbeeld 2:

Laten we het gewoon aanpassen bestand6.txt en leg de wijzigingen vast in het meester Afdeling.

Kijk naar de tweede regel in bestand6.txt waar het e-mailadres niet correct is opgegeven.

Maak een bugtak en los het probleem op. Wijzig tegelijkertijd ook file5.txt zodat we meerdere commits hebben gedaan in de bug branch, maar Cherry-Pick alleen de commit gedaan in file6.txt.

File6 gewijzigd in bug Afdeling.

Dus over het algemeen hebben we wijzigingen aangebracht in file5 en file6 in de Bug-tak.

Laten we nu teruggaan naar de meester branch en Cherry-Pick de commit die alleen voor file6.txt is gedaan.

Zoals je kunt zien, in plaats van het bug vertakking in de meester branch, hebben we zojuist Cherry-Picked alleen een specifieke commit en toegepast in de master branch.

Git Reset

Git reset is een krachtig commando om lokale wijzigingen ongedaan te maken. Dus om alle gefaseerde bestanden uit te schakelen, wordt deze opdracht gebruikt.

Voorbeeld

Wijzig een bestand en voeg het toe aan de staging. Reset met behulp van de opdracht zoals weergegeven wanneer de gefaseerde wijzigingen unstaged zijn.

Parameters van git reset opdracht.

-zacht: Deze parameter zal de HEAD naar een andere commit verwijzen. Alle bestanden worden veranderd tussen de originele HEAD en de vastlegging zal worden gestaged. De werkmap is intact.

Kijk naar de huidige HEAD-locatie.

Laten we 5 commits teruggaan in de geschiedenis.

Leg de wijzigingen opnieuw vast.

-gemengd: De optie is vergelijkbaar met de zachte parameter. Gewoonlijk, als er een aantal slechte commits zijn, verwijder je deze en repareer je het later en leg je het weer vast. Dus in wezen moeten we toevoegen aan de index met git add en toen git commit. Veranderingen blijven in de werkboom.

Laten we 2 commits teruggaan in de geschiedenis en kijken of de bestanden niet bijgehouden worden.

Voeg nu de bestanden toe aan enscenering en leg de wijzigingen vast.

-moeilijk: Deze parameter zal rusten tot een punt waarop een bepaald bestand bestond. De wijzigingen zijn niet beschikbaar in de werkboom.

Als we naar het bovenstaande logboek kijken, gaan we terug naar het punt waar alleen bestand 1 werd vastgelegd, d.w.z. de laatste invoer.

Gebruik makend van git reset –hard

Git Bisect

Vind de exacte commit die de code heeft gebroken (we zijn tenslotte allemaal mensen). Vaak horen we tijdens het testen van de applicatie van onze testers dat er een bug is of dat de feature kapot is en jij als ontwikkelaar zal zeggen dat het vorige week werkte. Dus, wat is er gebeurd en waarom is deze bug verschenen?

Soms kan een wijziging in de andere code van invloed zijn geweest op uw functie. Je moet tijd besteden aan het doornemen van de geschiedenis waar er veel commits zijn die tijdrovend en moeilijk te volgen zijn welke verandering ervoor zorgde dat de code brak.

Git Bisect is het commando om de exacte commit te vinden toen de bug werd geïntroduceerd. Met Git bisect moet je twee commits kiezen, een goede en een slechte. Ongeveer halverwege tussen beide commits zal worden uitgecheckt. Je controleert elke commit, hetzij slecht of goed, totdat de commit die ervoor zorgde dat de bug of code brak, is gevonden.

Voorbeeld:

• Maak een nieuwe lokale git-repository en maak een bestand met de naam index.html
• Oorspronkelijke inhoud van het bestand zoals weergegeven.

• Toevoegen aan enscenering en vastleggen in de repository.

• Maak een historie van commits zoals getoond, zodat we kunnen kiezen tussen goede en slechte commits. Nu de initiële vastlegging is voltooid, voert u de andere wijzigingen uit zoals getoond en legt u hetzelfde vast. In totaal zullen we 7 commits doen.

Tweede verandering

Derde wijziging

Vierde verandering

Vijfde verandering

Zesde wijziging

Zevende verandering

Laten we hier stoppen. We hebben dus zeven commits.

Als je naar de html-pagina kijkt, zijn de regels na 'Alle 4 gebeurtenissen ...' verkeerd en dus is de documentatie niet correct. We moeten dus de commit vinden waar de fout werd geïntroduceerd, zodat we onze HEAD op die commit kunnen rusten.

Laten we naar het logboek kijken en het slecht en goede inzet.

De laatste commit is niet juist, dus het kan een slechte commit zijn. De commit is geïntroduceerd na de derde commit, dus we kunnen de Derde wijziging als de goede commit.

Het proces van halveren begint met git halveren start en eindigt met git bisect reset.

git halveren slecht // Als laatste commit is slecht. Het is niet nodig om de vastleggings-ID op te geven.

git halveren goed

Je kunt nu zien dat HEAD nu tussen de helft van de slechte en goede commit in zit.

Kijk naar de inhoud van index.html en kijk of er een goede commit is. Zo niet, dan wordt de fout nog steeds niet gevonden.

Niet echt dat de fout nog steeds bestaat. De laatste regel is verkeerd. Dus we rennen ‘ git halveren bad ’. Er is nog steeds een slechte commit en de huidige inhoud is niet acceptabel.

De bovenstaande inhoud is correct en acceptabel.

Voer ‘git log –oneline’ en ‘git bisect good’ uit.

Dus de Vijfde verandering was de eerste slechte commit en echt zo. De fout wordt geïdentificeerd.

De huidige inhoud moet in de definitieve documentatie staan.

Als de slechte commit wordt geïdentificeerd, kun je de ontwikkelaar informeren om de wijzigingen te corrigeren die mogelijk zijn om de head te resetten naar de vierde wijziging die de laatste goede commit was.

Rennen ' git bisect reset ’Om het proces te beëindigen.

Gevolgtrekking

In deze praktische inleiding van GitHub hebben we geprobeerd alles te behandelen waaraan een ontwikkelaar zou moeten werken, d.w.z. vanuit het oogpunt van versiebeheer en tracking.

In de eerste drie tutorials van de GitHub-serie hebben we geleerd over versiebeheeractiviteiten, het maken van repositories, pull-verzoeken, branches, codebeoordelingen, organisaties en teams, fork a repository, labels, mijlpalen, issues, projectborden, wiki's, releases, integratie met Jira en enkele veelgebruikte Git-opdrachten voor ontwikkelaars.

We hopen echt dat alle ontwikkelaars deze praktische benadering voor GitHub en de Git-commando's nuttig zullen vinden in hun projecten.

​ Lees de Easy GitHub Training Series door.

Aanbevolen literatuur

• GitLab Jira Integration-zelfstudie
• Unix-opdrachten: basis- en geavanceerde Unix-opdrachten met voorbeelden
• Selenium-integratie met GitHub met behulp van Eclipse
• JIRA- en SVN-integratiehandleiding
• Git vs GitHub: ontdek de verschillen met voorbeelden
• Cucumber Selenium Tutorial: Cucumber Java Selenium WebDriver Integration
• GitHub-zelfstudie voor ontwikkelaars | Hoe GitHub te gebruiken
• Unix Pipes-zelfstudie: Pipes in Unix-programmering