Sådan bliver du en Git-ekspert

“Time-lapse-fotografering af en mand, der står ved siden af ​​vejen og broen på dagen” af Ahsan Avi på Unsplash

Jeg begik en fejl i min forpligtelse, hvordan løser jeg det?

Min engagementshistorie er et rod, hvordan gør jeg det pænere?

Hvis du nogensinde har haft ovenstående spørgsmål, så er dette indlæg noget for dig. Dette indlæg dækker en liste over emner, der vil gøre dig til Git-ekspert.

Hvis du ikke kender Git-basics, skal du klikke her for at tjekke min blog om Git-basics. Det er nødvendigt, at du kender det grundlæggende i Git for at udnytte denne artikel bedst muligt.

Jeg begik en fejl i min forpligtelse. Hvad skal jeg gøre?

“Ødelagt keramisk plade på gulvet” af chuttersnap på Unsplash

Scenario 1

Lad os sige, at du har begået en masse filer og er klar over, at den meddelelsesmeddelelse, du indtastede, faktisk ikke er klar. Nu vil du ændre engagement-meddelelsen. For at gøre dette kan du bruge git commit --end

git commit - ændre -m “Ny commit-meddelelse”

Scenario 2

Lad os sige, at du ønskede at begå seks filer, men ved en fejltagelse endte du kun med at begå fem filer. Du tror måske, at du kan oprette en ny engagement og tilføje den sjette fil til den forpligtelse.

Der er ikke noget galt med denne tilgang. Men for at opretholde en pæn forpligtelseshistorie, ville det ikke være pænere, hvis du rent faktisk på en eller anden måde kunne tilføje denne fil til din tidligere forpligtelse? Dette kan gøres gennem git commit - også ændre:

git tilføje fil6
git commit - ændre - ingen-redigering

- ingen redigering betyder, at meddelelsesmeddelelsen ikke ændres.

Scenario 3

Hver gang du foretager en forpligtelse i Git, har forpligtelsen et forfatternavn og forfatter-e-mail knyttet til det. Når du opretter Git for første gang, opretter du forfatternavnet og e-mailen. Du behøver ikke at bekymre dig om forfatteroplysningerne for hvert engagement.

Når det er sagt, er det muligt, at du for et bestemt projekt ønsker at bruge et andet e-mail-id. Du skal konfigurere e-mail-id'et for det projekt med kommandoen:

git config user.email “din e-mail-id”

Lad os sige, at du har glemt at konfigurere e-mailen og allerede gjorde din første forpligtelse. Ændring kan også bruges til at ændre forfatteren til din tidligere forpligtelse. Forfatteren af ​​engagementet kan ændres ved hjælp af følgende kommando:

git commit --end - forfatter "Forfatternavn "

Peg på note

Brug kun ændringskommandoen i dit lokale arkiv. Brug af ændring til fjernlageret kan skabe en masse forvirring.

Min forpligtelseshistorie er et rod. Hvordan håndterer jeg det?

Lad os sige, at du arbejder på et stykke kode. Du ved, at koden tager cirka ti dage at udfylde. Inden for disse ti dage overfører de andre udviklere også kode til fjernlageret.

Det er en god praksis at holde din lokale depotkode opdateret med koden i fjernlageret. Dette undgår mange flettekonflikter senere, når du rejser en pull-anmodning. Så du beslutter, at du vil trække ændringerne fra fjernlageret en gang hver anden dag.

Hver gang du trækker koden fra det eksterne arkiv til det lokale arkiv oprettes der en ny fletningskommission i dit lokale depot. Dette betyder, at din lokale forpligtelseshistorie vil have en masse sammenføjningsforpligtelser, der kan få tingene til at se forvirrende ud for anmelderen.

Sådan ser engagementshistorikken ud i dit lokale arkiv.

Hvordan får du tilsagnshistorien til at se pænere ud?

Det er her rebase kommer til undsætning.

Hvad er omlægning?

Lad mig forklare dette gennem et eksempel.

Dette diagram viser forpligtelserne i frigørelsesgrenen og din funktionsgren
  1. Release-grenen har tre forpligtelser: Rcommit1, Rcommit2 og Rcommit3.
  2. Du oprettede din Feature-gren fra Release-grenen, da den kun havde en engagement, hvilket er Rcommit1.
  3. Du har tilføjet to forpligtelser til Feature-grenen. De er Fcommit1 og Fcommit2.
  4. Dit mål er at få forpligtelserne fra Release-grenen til din Feature-gren.
  5. Du vil bruge rebase til at gøre dette.
  6. Lad navnet på frigørelsesgrenen frigives, og navnet på funktionsgrenen være funktion.
  7. Genfasning kan udføres ved hjælp af følgende kommandoer:
git checkout-funktion
git rebase release

Rebasing

Mens du rebase, er dit mål at sikre, at Feature-grenen får den seneste kode fra Release-grenen.

Genfasning forsøger at tilføje hvert engagement, en efter en, og kontrollerer for konflikter. Lyder det forvirrende?

Lad mig forklare ved hjælp af et diagram.

Dette viser, hvad rebasing faktisk gør internt:

Trin 1

  1. I det øjeblik du kører kommandoen, er Feature-grenen peget på chefen for frigørelsesgren.
  2. Nu har Feature-grenen tre forpligtelser: Rcommit1, Rcommit2 og Rcommit3.
  3. Du spekulerer måske på, hvad der skete med Fcommit1 og Fcommit2.
  4. Forpligtelserne er stadig der og vil blive brugt i trinnene herunder.

Trin 2

  1. Nu prøver Git at tilføje Fcommit1 til Feature-grenen.
  2. Hvis der ikke er nogen konflikt, tilføjes Fcommit1 efter Rcommit3
  3. Hvis der er en konflikt, giver Git dig besked, og du bliver nødt til at løse konflikten manuelt. Når konflikten er løst, skal du bruge følgende kommandoer til at fortsætte med at rebasere
git tilføje fast fil
git rebase - fortsæt

Trin 3

  1. Når Fcommit1 er tilføjet, vil Git forsøge at tilføje Fcommit2.
  2. Igen, hvis der ikke er nogen konflikt, tilføjes Fcommit2 efter Fcommit1, og rebasen er vellykket.
  3. Hvis der er en konflikt, giver Git dig besked, og du bliver nødt til at løse det manuelt. Brug de samme kommandoer, der er nævnt i trin 2 efter løsning af konflikter
  4. Når hele rebase er afsluttet, vil du bemærke, at Feature-grenen har Rcommit1, Rcommit2, Rcommit3, Fcommit1 og Fcommit2.

Punkter at bemærke

  1. Både Rebase og Merge er nyttige i Git. Den ene er ikke bedre end den anden.
  2. I tilfælde af en fusion har du en fusionstilsagn. I tilfælde af en genfase er der ikke nogen ekstra begivenhed som en fusionskommission.
  3. En bedste praksis er at bruge kommandoerne på forskellige punkter. Brug rebase, når du opdaterer dit lokale kodelager med den seneste kode fra fjernlageret. Brug fletning, når du har at gøre med pull-anmodninger om at flette Feature-grenen tilbage med frigivelses- eller mastergrenen.
  4. Brug af Rebase ændrer engagementhistorikken (det gør det pænere). Men når det er sagt, at ændre engagementhistorikken er det risici. Så sørg for, at du aldrig bruger omklassificering på en kode, der er der i fjernlageret. Brug altid rebase kun til at ændre engagementhistorikken for din lokale repokode.
  5. Hvis rebase udføres til et fjernlager, kan det skabe megen forvirring, da andre udviklere ikke genkender den nye historie.
  6. Hvis der foretages rebase på fjernlageret, kan det også skabe problemer, når andre udviklere prøver at trække den seneste kode fra fjernlager. Så jeg gentager igen, brug altid rebase kun til det lokale arkiv

tillykke

Du er nu en Git-ekspert

I dette indlæg har du lært om:

  • ændringsforpligtelser
  • variablernes vægtgrundlag

Begge disse er meget nyttige koncepter. Gå på udforsk verden af ​​Git for at lære endnu mere.

Om forfatteren

Jeg elsker teknologi og følger udviklingen på området. Jeg kan også godt lide at hjælpe andre med min teknologikendskab.

Du er velkommen til at oprette forbindelse til mig på min LinkedIn-konto https://www.linkedin.com/in/aditya1811/

Du kan også følge mig på twitter https://twitter.com/adityasridhar18

Min hjemmeside: https://adityasridhar.com/

Andre indlæg af Me

Bedste fremgangsmåder, mens du bruger Git

En introduktion til Git

Sådan bruges Git effektivt