Разлика между Git Rebase и сливане

Git е разпределена система за контрол на версиите - инструмент за проследяване на промените, направени в набор от файлове или координиране на работата във времето. Често се използва от програмистите за координиране на промените в изходния код на софтуера и най-добрата част; може да се използва за проследяване на всякакъв вид съдържание изобщо. Той е специално проектиран да управлява всичко от малки до големи обеми проекти с максимална скорост и ефективност. Това е изключително гъвкаво значение, индивидите могат да споделят работа директно между своите лични хранилища, а групите могат да координират работния си процес чрез централно хранилище. Той просто позволява на двама разработчици, седящи на две различни места, да правят и записват промени независимо, всички без централно хранилище.

Сливането е често срещана практика в Git, използвана за интегриране на промени от един клон в друг. Git merge е команда, която извършва промени в друго местоположение. Тя позволява на разработчиците да вземат своите независими редове от код, създадени от клона на Git и да ги интегрират в един клон. Това променя само целевия клон, докато историята на клона източник остава. Git rebase е още една команда, използвана основно за същата цел, с изключение на това, че го прави съвсем различно. И двамата правят едно и също нещо - интегрират ангажименти от един клон в друг, но разликата се състои в това как го правят. Изтъкваме някои основни отличителни точки, сравнявайки двете.

Какво е Git Merge?

Git merge е команда, която обединява две или повече клонове на историята на ангажиране. Сливането често обединява само два клона, въпреки че Git поддържа обединяване на три, четири или повече клона едновременно. Git merge се използва от Git pull, за да включи промените от един клон в друг или изобщо от друго хранилище. Обединяването трябва да се извърши в едно хранилище, което означава, че всички клонове, които трябва да се обединят, трябва да присъстват в едно и също хранилище. Ситуациите за сливане обикновено са резултат от двама или повече потребители, които се опитват да актуализират общ код. Най-често потребителят обединява клон в друг клон в локалното си хранилище в локална среда. Git merge конкретно интегрира съдържанието на изходния клон с целевия клон. Целевият клон е променен, докато изходният клон остава.

Какво е Git Rebase?

Git rebase е още една алтернатива на обединяването, използвано за интегриране на друг клон с клона, в който работите в момента, с изключение на това, че съхранява линейна история на ангажименти. Целта на Git rebase е да премести клон от едно място на друго. Тъй като поръчките са неизменни, те не могат да бъдат преместени, така че това води до извършване на нови ангажименти със същите набори промени и метаданни. Ребазата изменя съществено понятието кога и къде е разработена последователност от ангажименти, което води до загуба на някои аспекти от историята на развитието. Това означава, че първоначалният ангажимент, на който първоначално се основава разработката, ще бъде променен. Той ефективно включва всички нови ангажименти в основния клон чрез пренаписване на историята. В резултат на това създава нови ангажименти за всеки ангажимент в оригиналния клон.

Разлика между Git Rebase и Merge

1. Основи на Git Rebase и сливане

- Въпреки че и сливането, и повторното базиране са най-често срещаните начини за интегриране на промените в Git и те имат една и съща цел - да комбинират множество клонове в един - разликата се състои в това как те го постигат. Git merge интегрира съдържанието на изходния клон с целевия клон, като същевременно запазва родословието на всяка история на ангажименти, докато Git rebase включва всички нови ангажименти в главния клон, като пренаписва историята, създавайки нови комити за всеки ангажимент в клона на източника.

2. Работа на Git Rebase и сливане

 - С Git merge първо превключвате към клона, който ще бъде обединен, и след това използвате командата merge, за да изберете клон, който да се слее. Като се има предвид, че клон сочи към ангажимент и че команда е детайлността, с която асоциирате промените, сливането команда се обединява на ниво клон или ангажиране. Rebase, от друга страна, е малко по-различен. Първо избирате клон за повторно базиране и след това използвате командата rebase, за да изберете къде да го поставите.

3. Цел на Git Rebase и сливане

 - Сливането създава нов ангажимент, който представлява сливането между два клона. Тя интегрира промените от различни успоредни линии на развитие (клонове) заедно, като създава ангажимент за сливане. Целта е да се обединят два или повече клона заедно, включително всички промени от момента на разминаване в текущия клон. Бързо напред е поведението за сливане по подразбиране в Git. Освобождаването, от друга страна, променя отделни ангажименти чрез пренаписване на историята на проектите, като създава нови команди за всеки ангажимент в оригиналния клон, което от своя страна води до линейна история без разминаващи се клонове.

4. История на Git Rebase и сливане

- Git сливането не променя историята, като същевременно запазва контекста на клона, което означава, че съществуващите клонове не се променят по никакъв начин. Той създава нов ангажимент (освен ако не е бил бързо сливане напред), но комитите остават достъпни от клона. Git rebase, от друга страна, оптимизира потенциално сложна история. Комитетите се пренаписват, старите версии се забравят и DAG на ревизиите се променя. Комисиите вече не са достъпни с база данни, което означава, че вече не можете да пребазирате публикуваните клонове.

Rebase спрямо сливане: сравнителна диаграма

Обобщение на Git Rebase Vs. Merge

Накратко, сливането и повторното базиране са двата начина за интегриране на промените в Git, но те се различават по начина, по който го правят. Сливането е операция в една стъпка с едно място за разрешаване на конфликти и ангажиментите, които са били достъпни от клона, остават достъпни. Rebase, от друга страна, реагира всеки ангажимент поотделно чрез пренаписване на историята чрез създаване на нови ангажименти за всеки ангажимент в клона на източника. Така че това, което някога е било достижимо, вече не е достъпно. Ребазацията променя съществено понятието кога и къде е разработена последователност от ангажименти.