advanced git commands
Denna handledning utforskar användbara Git-kommandon som Git Stash, Git Reset, Git Cherry Pick, Git Bisect och förklarar hur man integrerar GitHub med Jira:
I våra tidigare handledning i denna serie har vi sett de flesta funktionerna i GitHub.
I denna handledning kommer vi att titta på följande:
- Skapa releaser
- Integration med Atlassian Jira
- Oftast använda Git-kommandon för utvecklare
- Git Stash
- Git Cherry Pick
- Git Återställ
- Git Bisect
=> Ta en titt på GitHub-guiden här.
världens bästa datahackingsprogramvara gratis nedladdning
Vad du kommer att lära dig:
- Skapa releaser
- GitHub-integration med Jira
- Avancerade Git-kommandon för utvecklare
- Slutsats
- Rekommenderad läsning
Skapa releaser
Releaser i GitHub används för att samla din programvara, lägga till release-anteckningar och binärer (WAR, EAR, JAR-filer) så att kunder och människor kan använda samma.
För att skapa en release, gå till förvarets huvudsida och klicka på Släpp flik under Hantera ämnen.
Klicka på Skapa en ny version.
Ange en tagg och en release-titel. Binärfilerna läggs också till i utgåvan. När du är klar klickar du på Publicera release.
Släppet är nu klart med källkoden och binärfilerna.
GitHub-integration med Jira
En av de viktiga spårbarhetsaspekterna är att referera till Jira-frågan med åtagandena i GitHub. GitHub kan integreras med Jira inte bara för att referera till problemet utan också för att skapa filialer och Pull Request inifrån Jira.
Så typiskt, när utvecklaren börjar arbeta med uppgiften eller buggar, skapas en gren av honom. Lägg upp utvecklingen eller lösa buggarna, en dragförfrågan kan skapas från Jira för att slå samman huvudet bemästra gren. Filialen som skapats av utvecklaren kan sedan raderas.
För att skapa integrationen har vi använt ett plugin Git Integration för Jira. Detta är ett kommersiellt plugin. Plugin-programmet kan laddas ner från här
Installera plugin-programmet i Jira från Admin -> Tillägg.
När plugin är installerat går du till Tillämpning -> Git-arkiv och anslut till GitHub.
Ange GitHub-användarnamnet och lösenordet. Klick Ansluta .
Förvaren som nämns för användarkontot visas. Klicka på Importera arkiv för att avsluta installationen.
GitHub åtar sig med Jira-frågan
Som en del av engagemangsmeddelandet anger du som visas nedan. Klicka på Begå förändringar .
Exempel 1: Nedan följer ett exempel på Smart åtagande vilket gör det möjligt för utvecklarna att utföra åtgärder på Jira-frågorna från engagemangsmeddelandet. Ett sådant kommando är #kommentar tillsammans med Issue-nyckeln som lägger till kommentaren till Jira-problemet som visas nedan.
Kommentars avsnitt uppdaterat.
Exempel 2: Tilldela en användare och uppdatera tiden som spenderas som 4 timmar.
Använd #tilldela och #tid smart commit-kommando i kommunicera meddelandet.
Båda åtgärderna har slutförts.
Exempel 3: Ändra status för problemet till Pågående .
Skapa en filial
Eftersom uppgifter och buggar tilldelas utvecklare måste de börja arbeta med utvecklingen. För detta skapar de en filial för den fråga de jobbar med, gör utvecklingsaktiviteterna och tar upp en pull-begäran om att gå samman i mastergrenen.
Klicka på i Jira-utgåvan längst ner Skapa filial.
Klicka på Skapa filial.
I GitHub gör du en ändring av filen i den ovan skapade filialen och gör samma.
När utvecklingen är klar kan användaren sedan ta fram en Pull-begäran från Jira.
Klicka på längst ned i frågan Skapa Pull Request.
Klicka på Skapa. Pull-begäran visas som öppen.
Nästa steg är att slå samman dragbegäran i GitHub.
Status uppdateras därefter i Jira.
Avancerade Git-kommandon för utvecklare
I det sista avsnittet kommer vi att titta på några av de vanliga Git-kommandona för utvecklare. Inget att göra med GitHub men hjälper utvecklarna innan de driver ändringarna till GitHub.
Git Stash
I de flesta av projektscenarierna när du arbetar med en ny funktion eller förbättring skulle det plötsligt vara ett behov av att du arbetar på en brådskande defekt som har rapporterats och är en show stopp. När du är halvvägs in i ditt nya arbete och inte slutfört det är det ingen mening att begå ändringarna som är halvklara.
Så det är bättre att stänga av eller spara det halvfärdiga arbetet tillfälligt, arbeta med felet och komma tillbaka till arbetet med den nya funktionen eller förbättringen. Git stash ger en lösning på detta. Du kan enkelt byta sammanhang för att göra ändringar snabbt.
Exempel 1 :Antag att du arbetar med en uppgift som tilldelats dig och när du tittar på statusen visar det att den inte är spårad från och med nu.
Plötsligt tilldelas du en högprioritetsfel. Således måste vi tillfälligt spara eller stash det arbete som för närvarande jobbar med.
Kör följande kommando.
git stash spara “Meddelande”
För närvarande är arbetskatalogen ren. Eventuella nya åtaganden kan göras och om det finns buggar kan du byta gren för att arbeta med det etc.
Använd kommandot när du vill tillämpa ändringarna där du hade kvar.
git stash pop
Ovanstående kommando tar bort stashen från listan och tillämpar det senast sparade tillståndet.
Du kan också använda:
git stash gäller
Ovanstående kommando behåller ändringarna i stash och tar inte bort dem.
Nu tillämpas ändringarna igen och du kan göra ändringarna.
Exempel 2: Stash dina ändringar, byt gren och slå samman ändringar.
Gör ändringen av Html-filen i bemästra gren och stash förändringar.
Nästa är att byta till insekt filial, göra ändringar och göra ändringar.
git checkout -b bug
Gör ändringar i HTML-filen.
git commit -a -m “Fixat e-postproblem”
Byt tillbaka till bemästra gren och använd ändringar från stash igen.
Slå nu samman från insekt gren till bemästra gren. Genomför ändringarna efter sammanslagningen.
Exempel 3: Arbeta med flera stash.
I den lokala repo finns två Html-filer. Så det är möjligt att flera utvecklare skulle arbeta med flera filer och stasha ändringar efter behov för att arbeta med brådskande förfrågningar som kommer för att fixa ändringarna.
Utvecklare 1 fungerar på hello.html och utvecklare 2 fungerar på index.html.
Utvecklare 1
Stash-listan har 1 post nu.
Utvecklare 2
Stash-listan har nu 2 poster. Det senaste stashet är först i stacken som är stash @ {0}. Nu kan båda utvecklarna göra andra åtaganden snarast eller arbeta på någon annan gren och sedan komma tillbaka till bemästra gren och applicera stashändringarna.
För att tillämpa det senaste stashet kan du bara springa
git stash pop
För att tillämpa en specifik stash i stacken kör du följande kommando.
git stash pop stash @ {1}
Låt oss applicera det andra stashet som är stash @ {1}
På samma sätt kan det andra stashet appliceras.
Git Cherry Pick
Idag arbetar utvecklarna med flera grenar som funktion, förbättring, fel etc.
Det finns situationer där endast ett par specifika åtaganden behöver plockas och inte slår samman hela filialen till en annan gren. Detta kallas en Cherry Pick. Den här processen låter dig godtyckligt välja alla Git-åtaganden från de andra grenarna och lägga till den till det aktuella HEAD för arbetsträdet.
Exempel 1:
I det lokala git-arkivet har vi följande 6 filer.
En fil raderas säg fil5.txt.
Genomför ändringarna.
Titta på loggen nu. File5.txt raderas.
Så vi vill Cherry-Pick åtagandet där vi lade till file5.txt. Vi måste hitta kommit-id för file5.tx och köra kommandot.
git cherry pick
I det här fallet är engagemangs-idet när file5.txt lades till a2f0124
File5.txt återställs nu. Vi valde Cherry-plikten.
Exempel 2:
Låt oss bara modifiera file6.txt och begå ändringarna i bemästra gren.
Titta på andra raden in file6.txt där e-postmeddelandet inte anges korrekt.
Skapa en buggfilial och åtgärda problemet. Ändra samtidigt file5.txt också så att vi har flera åtaganden i felgrenen men kommer Cherry-Pick bara att göra det i file6.txt.
File6 modifierad i insekt gren.
Så totalt sett har vi gjort ändringar i file5 och file6 i Bug-grenen.
Låt oss nu byta tillbaka till bemästra filial och Cherry-Pick bara görs för file6.txt.
Som du kan se det istället för att slå ihop insekt gren till bemästra gren, vi har bara Cherry-Picked bara ett specifikt engagemang och tillämpat i mastergrenen.
Git Återställ
Git reset är ett kraftfullt kommando för att ångra lokala ändringar. Så, för att ta bort scenen, används alla de iscensatta filerna som detta kommando.
Exempel
Ändra en fil och lägg till den i iscensättningen. Återställ med kommandot som visas när de iscensatta ändringarna inte är iscensatta.
Parametrar för git reset kommando.
-mjuk: Den här parametern kommer att peka HEAD på ett annat engagemang. Alla filer ändras mellan den ursprungliga HEAD och engagemanget kommer att iscensättas. Arbetskatalogen är intakt.
Titta på den aktuella HEAD-platsen.
Låt oss gå tillbaka fem åtaganden i historien.
Återför ändringarna.
-blandad: Alternativet liknar den mjuka parametern. Vanligtvis, när det finns några dåliga åtaganden, tar du bort dem och fixar det senare och gör det tillbaka. Så i huvudsak måste vi lägga till index med git add och då git begå. Ändringar finns kvar i arbetsträdet.
Låt oss gå tillbaka två åtaganden i historiken och se att filerna inte spåras.
Lägg nu till filerna i iscensättningen och gör ändringarna.
-hård: Denna parameter vilar till en punkt där en viss fil existerade. Ändringarna är inte tillgängliga i arbetsträdet.
Om vi tittar på ovanstående logg kan vi gå tillbaka till den punkt där endast fil 1 gjordes, dvs. den senaste posten.
Använder sig av git reset – hård
Git Bisect
Hitta det exakta åtagandet som bröt koden (Vi är ju alla människor). Ofta under test av applikationen hör vi från våra testare att det finns ett fel eller att funktionen är trasig och du som utvecklare kommer att säga att den fungerade förra veckan. Så, vad hände och varför dyker detta fel upp?
Ibland kan en förändring av den andra koden ha påverkat din funktion. Du måste spendera tid på att gå igenom historien där det finns många åtaganden som är tidskrävande och svårt att spåra vilken förändring som orsakade att koden bryts.
Git Bisect är kommandot för att hitta det exakta engagemanget när felet introducerades. Med Git bisect måste du välja två åtaganden, en bra och en dålig. Ungefär halvvägs mellan båda åtagandena kommer att checkas ut. Du kontrollerar att varje begå antingen är dålig eller bra tills begreppet som orsakade att felet eller koden bryts hittas.
Exempel:
- Skapa ett nytt lokalt git-arkiv och skapa en fil som heter index.html
- Det ursprungliga innehållet i filen som visas.
- Lägg till staging och förbinda dig till förvaret.
- Skapa en historik över åtaganden som visas, så att vi kan välja mellan bra och dåliga åtaganden. Nu när det första åtagandet är gjort gör de andra ändringarna som visas och gör samma. Sammantaget kommer vi att göra 7 åtaganden.
Andra ändringen
Tredje förändringen
Fjärde förändringen
Femte förändringen
Sjätte förändringen
Sjunde förändringen
Låt oss stanna här. Så vi har sju åtaganden.
Om du tittar på Html-sidan är raderna efter “Alla de 4 händelserna ...” felaktiga och därmed är dokumentationen inte korrekt. Så vi måste hitta engagemanget där felet infördes så att vi kan vila vår HEAD på det åtagandet.
Låt oss titta på loggen och ta reda på dålig och bra begå.
Det senaste åtagandet är inte rätt, så det kan vara ett dåligt åtagande. Åtagandet infördes efter det tredje åtagandet, så att vi kan få det Tredje förändringen som de goda begår.
Processen med halvering börjar med git bisect start och slutar med git bisect reset.
git bisect dåligt // Eftersom senaste åtagande är dåligt. Inget behov av att ange engagemangs-id.
git halva bra
Du kan nu se att HEAD nu ligger mellan hälften av det dåliga och goda engagemanget.
Titta på innehållet i index.html och se om det finns ett bra engagemang. Om inte, hittas felet fortfarande inte.
Inte riktigt att felet fortfarande finns. Den sista raden är fel. Så vi kör git bisect bad '. Det finns fortfarande ett dåligt engagemang och det aktuella innehållet är inte acceptabelt.
Ovanstående innehåll är korrekt och acceptabelt.
Kör 'git log –oneline' och 'git bisect good'.
Så, den Femte förändringen var det första dåliga åtagandet och verkligen så. Felet identifieras.
Det aktuella innehållet ska finnas i den slutliga dokumentationen.
Eftersom det dåliga engagemanget identifieras kan du informera utvecklaren om att korrigera ändringarna som kan vara för att återställa huvudet till den fjärde ändringen som var den senaste goda förpliktelsen.
Springa ' git bisect reset För att avsluta processen.
Slutsats
I denna GitHub hands-on-primer har vi försökt täcka allt som en utvecklare skulle behöva arbeta med, dvs. från versionskontroll och spårningssynpunkt.
I de tre första självstudierna i GitHub-serien har vi lärt oss om versionskontrollaktiviteter, skapa förvar, pull-begäran, filialer, kodrecensioner, organisationer och team, gaffla ett förvar, etiketter, milstolpar, problem, projektstyrelser, wikis, utgåvor, integration med Jira och några vanliga Git-kommandon för utvecklare.
Vi hoppas verkligen att alla utvecklare skulle hitta den här praktiska metoden för GitHub och Git-kommandona användbara i sina projekt.
=> Läs igenom Easy GitHub Training Series.
Rekommenderad läsning
- GitLab Jira Integration Tutorial
- Unix-kommandon: Grundläggande och avancerade Unix-kommandon med exempel
- Selenintegration med GitHub med Eclipse
- JIRA och SVN Integration Tutorial
- Git vs GitHub: Utforska skillnaderna med exempel
- Gurka Selen Tutorial: Gurka Java Selen WebDriver Integration
- GitHub-handledning för utvecklare | Hur man använder GitHub
- Unix Pipes Tutorial: Pipes in Unix Programming