Разлика между Git ReBase срещу сливане
В тази статия ще обсъдим два такива инструмента Rebase и Merge и тяхната разлика. GIT е един от най-често използваните контролери на DVCS за разпределени версии сред програмистите поради динамичния си характер и огромната наличност на инструменти за работа с версиите. Има два начина, с които можем да изпращаме промените си от един клон в друг. Единият е с помощта на Rebase, а другият е Merge, който е доста популярен. По-долу научаваме топто Сравнение между Git ReBase и Merge.
Сравнение между главата на Git ReBase срещу Merge (Инфографика)
По-долу са първите 5 сравнения между Git ReBase и Merge:
Ключови разлики между Git ReBase срещу Merge
Нека да обсъдим ключовата разлика между Git ReBase срещу Merge:
1. Git Rebase
Git Rebase започва работата си от общ ангажимент между двата клона. Главна и функция, от тук тя сравнява и двете и улавя моменталната снимка на разликата, която се прави в един от клоните и след това я добавя към други. Нека да разгледаме това с екранните снимки по-долу.
Нека си представим, че имаме главен клон и най-новите ангажименти за него m2, както е показано на горния екран. От този ангажимент създаваме клон на характеристиките и направихме някои модификации и се ангажираме с f1 съобщение. Нека сега помислим, че някой е слял работата си за овладяване и сега последният ангажимент на капитана е m3, а не m2, както е показано по-долу.
И ние също продължаваме да работим върху клона с функции, за да добавим последния си ангажимент да бъде f2, както е показано по-долу.
Както се вижда от по-горе screengrab, ние усвоихме най-новия фиксиран m3 и имаме функция, която не е в крак с главния, тъй като е създадена от m2 снимка на снимка, която има най-новия фикс като f3. Сега, за да комбинирате тези усилия с главния генериращ, е показано по-долу.
Сега трябва да интегрираме горните промени, които могат да бъдат направени по два начина: един с обединяване, а други с ребаза. Тук ще разгледаме как да се интегрираме с rebase.
$ git checkout feature
Switched to a new branch 'feature'
$ git rebase master
От горната команда на rebase ще се опитаме да потърсим общ ангажимент както от master, така и от функция и в този случай това е m2. И след това, тъй като трябва да пренастроим master, той ще търси допълнения, които са направени с master и ще вземе моментна снимка m3 и функция за пренастройка от m2 до m3. Така че сега имаме функция с m3 (вместо m2), f1, f2 ангажира. Сега мога да кандидатствам за повторно базиране на функцията, за да направя основния клон актуализиран с промените на функцията. Едно нещо, което трябва да запомните е, че всяка промяна в капитана трябва да бъде одитирана. Тук само показвам например цел.
$ git checkout master
Switched to a new branch 'master'
$ git rebase feature
Сега в това, ние ще приложим най-новия клон за фиксиране на фиксиране, който е f2 за овладяване, а най-късният момент на снимка на мастера ще бъде f2. Можете да изброите комисионите, като използвате командата git log, но първо трябва да проверим към кой клон трябва да видим дневника, както по-долу.
$ git checkout feature
Switched to a new branch 'feature'
$ git log
Сега с базата данни сме интегрирали актуализациите на функция, която да овладеем. Нека се опитаме да постигнем това чрез сливане.
2. Git Merge
Ще използваме горната снимка на екрана и за справка тук и можем да постигнем същото, което постигнахме и с rebase и сливане.
Git merge извършва последния ангажимент, който имахме в функцията клон и тук случаят е с f2 commit, който събира всички промени и го слива с най-новия ангажимент, който имаме в основния клон, m3 тук. Това изглежда сложно, но може лесно да се изпълни от командата за сливане. Можем да направим директно сливане или сливане на сквош и разликата и в двете.
$ git checkout master
Switched to a new branch 'master'
$ git merge feature
Горната команда ще поеме всички елементи на функцията и ще добави и в дневника на главния. За да избегнем, че можем да използваме скуош, така че в дневника на капитана, след m3 ще направим само един ангажимент и това е актуализация
$ git checkout master
Switched to a new branch 'master'
$ git merge –squash feature
човек трябва да бъде внимателен, докато използвате git rebase и да се опитате да го избегнете. Златното правило е да се избягва използването на публични клонове.
Просто погледнете горния сценарий. Това може да се случи, когато се опитате да пребазирате master над вашия филиал за функции и основният ни клон е публичен, сега основният клон е актуализиран, но всички останали работят върху по-стара версия на master. Тъй като освобождаването ще доведе до чисто нови ангажименти, git може да мисли, че историята на главния клон се е различила от всички останали. Единственият начин да се реши това е да се синхронизират и двете главни, като ги обединят отново и имат резултат от набор от ангажименти, които ще бъдат объркващи.
Таблица за сравнение на Git ReBase срещу сливане
Таблицата по-долу обобщава сравненията между Git ReBase и Merge:
| Основа на сравнението между Rebase vs Merge | Rebase | Merge |
| Ангажира | Той променя и пренаписва историята, като създава нов ангажимент за всеки ангажимент в клона на източника. | Той включва всички промени в източника, но поддържа родословието на всяка история на ангажиментите, включва всички промени в източника, но поддържа родословието на всяка история на ангажиментите. |
| селекция | Тук първо проверяваме клона, който трябва да се пребазира, след което избираме командата rebase за да добавите актуализации към други. | Тук първо проверете клона, който първо трябва да бъде обединен. След това извършете операцията по сливане и последния запис на източника ще бъдат слети с последния ангажимент на капитана. |
| Работа с конфликти | Тъй като историята на ангажиментите ще бъде пренаписана, за да се разбере конфликтът ще бъде трудно някои случаи. | Конфликтът на сливане може лесно да се справи с разбирането на грешката, която е извършена при сливането. |
| златно правило | Трябва да се използва в публичните клонове, тъй като историята на ангажиментите може да доведе до объркване. | Няма голяма вреда по време на изпълнение на публични клонове. |
| Достъпност | Комисиите, които някога са били достъпни, вече няма да бъдат достъпни след повторно базиране, тъй като историята на ангажиментите е променена. | Комитетите ще останат достъпни от клоновете на източника. |
заключение
Merge and Rebase са няколко два мощни инструмента на Git и двата се използват за включване на промените в клоновете, но трябва да сме малко внимателни с rebase, тъй като тя ще пренапише историята на комитите и използването им в обществени клонове може да попречи на работата на други, причинявайки им объркване. Като има предвид, че можете да използвате опцията за сливане, тъй като нейните ангажименти са достъпни от клона на източника и могат лесно да разрешат конфликтите за сливане, ако имаме правилно разбиране.
Препоръчителни статии
Това е ръководство за най-високата разлика между Git ReBase срещу Merge. Тук също обсъждаме ключовите разлики в Git ReBase срещу Merge с инфографика и таблица за сравнение. Може да разгледате и следните статии, за да научите повече -
- Git Fetch vs Git Pull - Топ разлики
- Абстракция срещу капсулация | Топ 6 сравнение
- HBase Архитектура с предимства
- Въпроси за интервю за GIT | Топ 11
- Система за управление на версиите GIT
- Git Push
- Капсулиране в JavaScript
- Пълно ръководство за дистанционно командване на Git
- Три етапа от жизнения цикъл на Git с работния процес
- Как да използвате GIT Cherry-pick с пример?