av Vali Shah

som utvecklare måste många av oss välja mellan Merge och Rebase. Med alla referenser vi får från internet tror alla ” använd inte Rebase, det kan orsaka allvarliga problem.”Här kommer jag att förklara vad merge och rebase är, varför du ska (och bör inte) använda dem, och hur man gör det.

Git Merge och Git Rebase tjänar samma syfte. De är utformade för att integrera förändringar från flera grenar till en., Även om det slutliga målet är detsamma, uppnår de två metoderna det på olika sätt, och det är bra att veta skillnaden när du blir en bättre mjukvaruutvecklare.

denna fråga har delat upp Git-diskussionsgruppen. Vissa tror att du alltid bör rebase och andra som du alltid bör slå samman. Varje sida har några övertygande fördelar.

Git Merge

sammanslagning är en vanlig praxis för utvecklare som använder versionskontrollsystem. Om grenar skapas för testning, buggfixar eller andra skäl, förbinder sammanslagning ändringar till en annan plats., För att vara mer specifik, sammanslagning tar innehållet i en källa gren och integrerar dem med ett mål gren. I denna process ändras endast målgrenen. Källgrenshistoriken förblir densamma.,da2a4595a”>

Merge Master -> feature branch

fördelar

  • enkel och bekant
  • bevarar fullständig historia och kronologisk ordning
  • upprätthåller kontexten för filialen

nackdelar

  • felsökning med git bisectkan bli svårare

    • hur man gör det

    slå samman huvudgrenen i funktionen gren med hjälp av checkoutochmergekommandon.,

    $ git checkout feature$ git merge master(or)$ git merge master feature

    detta kommer att skapa en ny ”Merge commit” i funktionen gren som innehar historien om båda grenarna.

    Git Rebase

    Rebase är ett annat sätt att integrera förändringar från en gren till en annan. Rebase komprimerar alla ändringar i en enda ”patch.”Då integrerar den plåstret på målgrenen.

    till skillnad från sammanslagning, utjämnar rebasering historiken eftersom den överför det färdiga arbetet från en gren till en annan. I processen elimineras oönskad historia.,

    Rebaser är hur förändringar ska passera från toppen av hierarkin nedåt, och sammanslagningar är hur de flyter tillbaka uppåt

    Rebase funktion gren i master

    Pros

    • effektiviserar en potentiellt komplex historia
    • Det är enkelt att manipulera en enda begå (t. ex., återställa dem)
    • Undviker samman begå ”buller” i det livliga repor upptagen med filialer
    • Rengör mellanliggande förbinder sig genom att göra dem till en enda begå, som kan vara till hjälp för DevOps-lag

    Cons

    • Squash ” – funktionen ner till en handfull åtar sig kan dölja kontext
    • Rebasing offentliga arkiv kan vara farligt när man arbetar som ett team
    • Det är mer arbete: att Använda rebase att hålla din funktion branch uppdateras alltid
    • Rebasing med lokalkontor kräver att du force push., Det största problemet människor står inför är att de tvingar push men har inte ställt in git push-standard. Detta resulterar i uppdateringar till alla grenar med samma namn, både lokalt och på distans, och det är fruktansvärt att hantera.

    om du felaktigt och oavsiktligt skriver om historien kan det leda till allvarliga problem, så se till att du vet vad du gör!

    hur man gör det

    Gör om funktionen gren på huvudgrenen med följande kommandon.,

    $ git checkout feature$ git rebase master

    detta flyttar hela funktionen gren ovanpå huvudgrenen. Det gör detta genom att skriva om projekthistoriken genom att skapa helt nya åtaganden för varje begå i den ursprungliga (feature) grenen.

    interaktiv Rebasering

    detta gör det möjligt att ändra åtagandena när de flyttas till den nya grenen. Detta är kraftfullare än automatiserad rebase, eftersom det ger fullständig kontroll över filialens begå historia. Vanligtvis används detta för att städa upp en rörig historia innan man slår samman en funktionsgren till mästare.,

    $ git checkout feature$ git rebase -i master

    detta öppnar redigeraren genom att lista alla åtaganden som ska flyttas.

    pick 22d6d7c Commit message#1pick 44e8a9b Commit message#2pick 79f1d2h Commit message#3

    detta definierar exakt hur grenen kommer att se ut efter att rebase har utförts. Genom att ombeställa enheterna kan du få historien att se ut som vad du vill. Du kan till exempel använda kommandon som fixup, squash, edit etc, i stället för pick.

    vilken som ska användas

    Så vad är bäst?, Vad rekommenderar experterna?

    det är svårt att generalisera och bestämma det ena eller det andra, eftersom varje lag är annorlunda. Men vi måste börja någonstans.

    team måste överväga flera frågor när de ställer in sina git rebase vs merge-policyer. För som det visar sig är en arbetsflödesstrategi inte bättre än den andra. Det är beroende av ditt lag.

    överväga nivån på rebasing och Git kompetens i hela din organisation. Bestäm i vilken grad du värdesätter enkelheten i rebasing jämfört med spårbarhet och historia av sammanslagning.,

    slutligen bör beslut om sammanslagning och rebasering övervägas inom ramen för en tydlig förgreningsstrategi (se den här artikeln för att förstå mer om förgreningsstrategi). En framgångsrik förgreningsstrategi är utformad kring organisationen av dina lag.

    vad rekommenderar jag?

    när laget växer blir det svårt att hantera eller spåra utvecklingsändringar med en alltid sammanfogningspolicy. Att ha en ren och förståelig begå historia är att använda Rebase rimligt och effektivt.,

    genom att överväga följande omständigheter och riktlinjer kan du få ut det mesta av Rebase:

    • du utvecklar lokalt: om du inte har delat ditt arbete med någon annan. Vid denna tidpunkt bör du föredra ombokning över sammanslagning för att hålla din historia snygg. Om du har din personliga gaffel av förvaret och som inte delas med andra utvecklare, är du säker att rebase även efter att du har drivit till din gren.
    • din kod är klar för granskning: du skapade en pull-förfrågan. Andra granskar ditt arbete och hämtar det potentiellt i sin gaffel för lokal granskning., Vid denna tidpunkt bör du inte rebasera ditt arbete. Du bör skapa ”omarbeta” begår och uppdatera din funktion gren. Detta hjälper till med spårbarhet i pull begäran och förhindrar oavsiktlig historia brott.
    • översynen är klar och redo att integreras i målgrenen. Grattis! Du håller på att ta bort din funktion gren. Med tanke på att andra utvecklare inte kommer att hämta-sammanslagning i dessa förändringar från denna punkt på, detta är din chans att sanera din historia., Vid denna punkt, Du kan skriva historia och vika den ursprungliga begår och de irriterande ”pr omarbetningar” och ”merge” begår i en liten uppsättning fokuserade begår. Att skapa en explicit sammanfogning för dessa åtaganden är valfritt, men har värde. Den registrerar när funktionen graderade att bemästra.

    slutsats

    Jag hoppas att denna förklaring har gett några insikter om git merge och Git rebase. Merge vs rebase strategi är alltid diskutabelt. Men kanske kommer den här artikeln att hjälpa till att skingra dina tvivel och låta dig anta ett tillvägagångssätt som fungerar för ditt lag.