Phenquestions
Начинаещите в Git са предупредени срещу командата rebase. И с право. С всички нови неща, които трябва да научат, начинаещите вероятно са по-добре да овладеят основните концепции, преди да се задълбочат в тънкостите на пребазирането. Ако обаче разбирате основите на сливането на клонове, тогава знанието как да пренастроите може да ви помогне да решите някои сложни пъзели за развитие, когато дойде подходящият момент.
Git Rebase: Определения
Според документацията на git, командата rebase ще приложи отново ангажименти върху друг основен съвет. Това определение може да е малко плашещо. По-лесно е да се обясни rebase като процедура, която добавя промените на текущия клон към опашката на друг клон. Нека да разгледаме един пример, за да добием по-добра представа за това какво се случва.
Пример за преоценка на Git
В този пример първо ще създадем тестов случай с клон 'master' и 'feature'. След това ще направим стандартно сливане. След това ще пресъздадем тестовия случай и ще извършим пребазиране и обединяване.
1. Създаване на Master и Feature клонове
Ето сценария, който ще създадем:
A - B - C (главен) \ E - F (функция)
В горния пример поемаме по следния път:
- Ангажиране A: добавяме a.txt файл в клона „master“
- Фиксиране B: добавяме b.txt файл в клона „master“
- На този етап създаваме „характеристика“ на клона, което означава, че ще има.txt и b.текст
- Фиксиране C: добавяме c.txt файл в клона „master“
- Отиваме в клона „функция“
- Ангажиране E: ние модифицираме a.txt в клон „функция“
- Ангажиране F: модифицираме b.txt в клон „функция“
Можете да създадете папка и да изпълните следния код вътре в папката, за да създадете горната ситуация:
git init touch a.txt git add -A git commit -m "Ангажиране A: добавено a.txt "докоснете b.txt git add -A git commit -m "Ангажиране B: добавено b.txt "git клон функция докосване c.txt git add -A git commit -m "Ангажиране C: добавено c.txt "git status git checkout функция echo aaa> a.txt git add -A git commit -m "Ангажиране E: модифициран a.txt "ехо bbb> b.txt git add -A git commit -m "Ангажиране F: модифициран b.текст"
2. Обикновено сливане
Нека използваме командата log, за да проверим и двата клона.
Резултати за 'master':
$ git checkout master Превключен към клон 'master' $ git log --oneline 2bbde47 Ангажиране C: добавено c.txt b430ab5 Фиксиране B: добавено b.txt 6f30e95 Ангажиране A: добавено a.txt $ ls a.txt b.txt c.текст
Резултати за 'функция':
$ git checkout функция Превключено към разклонение 'feature' $ git log --oneline 0286690 Ангажиране F: модифициран b.txt 7c5c85e Фиксиране E: модифициран a.txt b430ab5 Фиксиране B: добавено b.txt 6f30e95 Ангажиране A: добавено a.txt $ ls a.txt b.текст
Забележете как клонът на характеристиките няма ангажимент C
Сега нека стартираме сливане на "характеристика" клон с "главен" клон. Ще бъдете помолени да въведете коментар. В коментара добавете „Ангажирай G:“ в началото, за да улесните проследяването.
$ git checkout master Превключен към клон 'master' $ git merge функция Обединяване, направено от 'рекурсивната' стратегия. а.txt | 1 + b.txt | 1 + 2 файла са променени, 2 вмъквания (+)
Резултати за 'master':
$ git checkout master Вече в 'master' $ git log --oneline d086ff9 Ангажиране G: Обединяване на клон 'функция' 0286690 Ангажиране F: модифициран b.txt 7c5c85e Фиксиране E: модифициран a.txt 2bbde47 Ангажиране C: добавено c.txt b430ab5 Фиксиране B: добавено b.txt 6f30e95 Ангажиране A: добавено a.txt $ ls a.txt b.txt c.текст
Резултати за 'функция':
$ git checkout функция Превключено към разклонение 'feature' $ git log --oneline 0286690 Ангажиране F: модифициран b.txt 7c5c85e Фиксиране E: модифициран a.txt b430ab5 Фиксиране B: добавено b.txt 6f30e95 Ангажиране A: добавено a.txt $ ls a.txt b.текст
В клона „master“ ще забележите, че има нов фиксиран G, който е обединил промените от клона „feature“. По принцип се е случило следното действие:
A - B - C - G (главен) \ / E - F (функция)
В записването G всички промени от клона на „характеристика“ са внесени в главния клон. Но самият клон „функция“ остава недокоснат поради процеса на сливане. Забележете хеша на всеки ангажимент. След обединяването, E (7c5c85e) и F (0286690) фиксация има един и същ хеш в клона „функция“ и „главен“.
3. Сливане с преоценяване
Нека повторим стъпка 1, за да създадем клонове „master“ и „feature“ отново.
Резултати за 'master':
$ git checkout master Превключен към клон 'master' $ git log --oneline 7f573d8 Ангажиране C: добавено c.txt 795da3c Фиксиране B: добавено b.txt 0f4ed5b Ангажиране A: добавено a.txt $ ls a.txt b.txt c.текст
Резултати за 'функция':
$ git checkout функция Превключено към разклонение 'feature' $ git log --oneline 8ed0c4e Ангажиране F: модифициран b.txt 6e12b57 Ангажиране E: модифициран a.txt 795da3c Фиксиране B: добавено b.txt 0f4ed5b Ангажиране A: добавено a.txt $ ls a.txt b.текст
Нека да пребазираме от клона „функция“.
$ git checkout функция Превключено към клон 'feature' $ git rebase master Първо, пренавиване на главата, за да преиграете работата си отгоре ... Прилагане: Ангажиране E: модифициран.txt Прилагане: Фиксиране F: модифициран b.текст
След това обединете „функция“ в „master“.
$ git checkout master Превключен към клон 'master' $ git merge функция Актуализиране на 7f573d8 ... 9efa1a3 Превъртане напред a.txt | 1 + b.txt | 1 + 2 файла са променени, 2 вмъквания (+)
Резултати за „master“ клон:
$ git checkout master Вече е в 'master' $ git log --oneline 9efa1a3 Ангажиране F: модифициран b.txt 8710174 Фиксиране E: модифициран a.txt 7f573d8 Ангажиране C: добавено c.txt 795da3c Фиксиране B: добавено b.txt 0f4ed5b Ангажиране A: добавено a.txt $ ls a.txt b.txt c.текст
Резултати за клон „функция“:
$ git checkout функция Превключено към клон 'feature' $ git log --oneline 9efa1a3 Ангажиране F: модифициран b.txt 8710174 Фиксиране E: модифициран a.txt 7f573d8 Ангажиране C: добавено c.txt 795da3c Фиксиране B: добавено b.txt 0f4ed5b Ангажиране A: добавено a.txt $ ls a.txt b.txt c.текст
Забележете, че след пребазирането и обединяването двата клона са еднакви. Също така хешовете за E и F са се променили и в двата клона. По принцип в сценария на пребазирането се случи следното:
A - B - C \ E '- F' (функция, главен)
Ето защо няма нов ангажимент. Ангажиментите E и F са преизчислени и фиксирани в края на клона „master“.
Преоценката е полезен инструмент, когато искате да изчистите историята на работата си. Съществува обаче опасност, която е родила златното правило.
Златно правило за преоценяване
Златното правило за преоценка е:
Никога не преоценявайте публичен клон.
Както можете да видите от примера по-горе, пребазирането преизчислява фиксирането. Когато множество хора се разклоняват от публично хранилище, пребазирането може да създаде ситуации, при които разработчиците, които са създали нови клонове, ще се сблъскат с много сложни ситуации на сливане. Така че, добра идея е никога да не преизчислявате публичните клонове, които се споделят.
В заключение:
Пребазирането е уникална характеристика на Git. Но използвайте го с повишено внимание.
Повече информация:
Ето няколко връзки за по-нататъшно проучване:
Git Rebase Документация
Atlassian Merging срещу Rebasing
Препратки:
- https: // www.атласки.com / git / tutorials / merging-vs-rebasing
- Контрол на версиите с Git - 07 - Rebase [https: // www.YouTube.com / watch?v = cSf8cO0WB4o]
- https: // git-scm.com / docs / git-rebase
- Какво е Git rebase? [https: // www.YouTube.com / watch?v = TymF3DpidJ8]
- https: // среда.безплатен лагер.org / git-rebase-and-the-golden-правило-обяснено-70715eccc372
