de flesta kodintegrationer hända med en sammanslagning, men ibland en utvecklare vill få sin lokala kod ikapp med huvudgrenen genom en rebase istället. I det här exemplet kommer vi att visa hur git rebase en gren att behärska istället för att använda kommandot merge, samtidigt som vi påpekar effekten av att utföra en git rebase till master-operation.
Vad betyder Git rebase till master?,
i den här guiden kommer vi att ta grenen heter utveckla och rebase den på spetsen av master.
utvecklingsgrenen bröt av från master vid commit C, så båda grenarna delar filerna a.html, b.html och c.html. – herr talman! Se bilden nedan för att visualisera detta.
sedan grenen inträffade har master lagt till begår d och E. Det betyder att master har två filer som utvecklas inte har, nämligen d.html och e.html. – herr talman!,
Så här ser git-arkivet ut innan en git-rebase till master.
dessutom, sedan splittringen, har det funnits två nya åtaganden på develop-filialen och lagt till filerna f.html och g.html. – herr talman! Det här är filer som develop-filialen har att huvudgrenen inte gör det.
Så här ser GitLab-arkivet ut efter git-rebasen att behärska.,
effekten av Git rebase
Efter en framgångsrik utveckling gren för att bemästra rebase:
- filerna i huvud grenen kommer inte att förändras
- utveckla grenen kommer dessutom förvärva alla Huvud grenens nya filer
- utveckla stream gren punkt kommer att förändras.
- Det kommer att visas som om utveckla grenen split efter commit E på huvudgrenen.
- före rebase delas utvecklingsgrenen från master at commit C.,
Git rebase till master command syntax
operationen för att utföra en Git rebase till master är rakt framåt. Lägg helt enkelt till slutet av kommandot namnet på källgrenen och sedan namnet på grenen för att rebase. Att rebase utveckla för att behärska kommandot är följande:
git rebase master develop
Varning: Det finns en git rebase på switch som ibland Utvecklare felaktigt tror att de behöver inkludera med rebase-kommandot. Om du gör det kommer det att leda till att begå sig att kasseras och filer förloras., Gör inte misstaget att utföra en git-rebase på drift.
före rebase hade develop-filialen bara fem filer.
varje gren har fem filer innan git rebase till master operation.
efter Git rebase att bemästra, utvecklar grenen har sju filer. Det har behållit alla sina ursprungliga filer och förvärvat två nya filer från spetsen på huvudgrenen., Antalet filer i huvudgrenen förblir dock oförändrat.
efter git rebase av Utveckla att bemästra, utvecklar filialen alla master filer.
det faktum att huvudgrenen inte förvärvade några filer från utvecklingsgrenen kastar ofta nya Git-användare av, men det här är det förväntade beteendet. En git rebase synkroniseras inte mellan grenar. Det fångar helt enkelt en gren upp med de senaste ändringarna från en annan.,
antalet filer som utvecklas ökar efter git rebase till master.
fortsätt med försiktighet
När en Git-rebase inträffar ändras arkivets begårhistorik oåterkalleligt. Efter rebase i vårt exempel, begår F och G tilldelas helt nya commit ID, och de gamla commit ID kasseras. Av denna anledning kommer du ofta att se rebased förbinder markerade som F ’och G’ att betona det faktum att nya kommittéer har tilldelats.,
om du gör om en filial som delas med en annan utvecklare och trycker tillbaka ändringarna till GitHub eller GitLab, kommer en annan utvecklare att stöta på en mängd eller problem när de försöker dra det rebased-arkivet i sin lokala utvecklingsmiljö. Förbinder de har lokalt kommer att ha försvunnit på fjärrkontrollen, och den avlägsna grenen kommer att ha en inkompatibel gren historia. Som ni kan föreställa er, rebasing en delad gren eller squashing Git begår kan utlösa havok.,
Rebase till GitHub eller GitLab
i själva verket, om du rebase och försöka driva till GitLab eller GitHub, servern kommer inte att tillåta att operationen utförs. För att rebase till GitHub eller GitLab måste en utvecklare lägga till –force-omkopplaren till GIT-pushkommandot för att tvinga de ändringar som ska accepteras.
git push origin --force
en GitLab eller GitHub rebase push kommer att avvisas om inte tvingas.,
den accepterade logiken är att endast git rebase till master grenar lokal till din personliga arbetsyta. På så sätt din Git städa upp kommandon påverkar inte någon annan. Utför inte en git-rebase för att behärska på grenar som delas med andra utvecklare. En rebase på master är bra, bara inte tvärtom. Annars kommer du sannolikt att bryta Bygg-och push-eller pull-operationerna att sättas på stand-by, omintetgöra fortsatt utveckling och göra dig persona non grata med resten av utvecklarna och DevOps-laget.