Git Reflog - Как да възстановите изтрит клон, който не е обединен



Тази статия за Git Reflog е изчерпателно ръководство за това как да възстановите изтритите разклонени в Git с помощта на Git Reflog.

„Загубили ли сте някога клон, чийто изходен код все още не е бил обединен в„ освобождаващия “или„ основния “клон? Ами ако искате да регенерирате изтрит клон, въпреки че работата му вече е обединена в основния клон? ' . Е, единственото решение за такива сценарии е Отидете Reflog .

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





    1. Какво е Git Reflog?
    2. Как и кога клонът се изтрива?
    3. Възстановете изтрит клон
    4. Каква работа се възстановява, когато изтритият клон се възстанови?
    5. Подкоманди Git Reflog

И така, нека започнем с тази статия.



Помислете за сценарий, a maintainer трябва да обедини много разклонения на функции от различни сътрудници и след това да ги изтрие в крайна сметка, но клонът се изтрива случайно, преди работата да може да бъде обединена?

Е, преди да премина към тази статия, нека ви кажа, че не е възможно в Git. са сигурни и действат като контролен пост не би ви позволил да го направите. И така, тук се появява Git Reflog.

Какво е Git Reflog?

TheКомандата ‘reflog’ поддържа a следи от всяка една промяна, направена в препратките (клонове или тагове) на хранилище и съхранява хронология на клоновете и таговете, които са били или създадени локално, или са отметени. Референтните дневници, като например моментната снимка на фиксирането, когато клонът е създаден или клониран, отметнат, преименуван или всякакви ангажименти, направени в клона, се поддържат от и изброени от командата ‘reflog’.



Забележка: Клонът ще може да бъде възстановен от вашата работна директория само ако клонът някога е съществувал във вашето локално хранилище, т.е. клонът е създаден локално или е изваден от отдалечено хранилище във вашето локално хранилище за Git, за да съхранява своите журнали на референтната история.

Тази команда трябва да се изпълни в хранилището, което е имало загубения клон. Ако помислите заситуация на отдалечено хранилище, тогава трябва да изпълните командата reflog на машината на разработчика, която е имала клон.

команда: отидете пререгистрирайте

Сега, след като знаете, какво е Git Reflog, позволете ниопитайте се да изтриете както обединения, така и не-обединения клон и да видите как Git се справя с това?

Стъпка 1: Избройте клоновете, които са обединени в master

Първо разгледайте „ майстор ’Клон, ако сте на друг клон с помощта на командата:

$ git checkout master

Изход

Git Checkout Master - Git Reflog - Edureka

Сега, за да получите списък на обединените клонове, споменете следната команда:

$ git клон - обединен

Изход:

Стъпка 1.1: След това изтрийте обединения клон:

$ git клон -d брой # 902

Изход:

Клонът ‘issue # 902’ беше успешно изтрит, тъй като вече е обединен в клона ‘master’.

Стъпка 2: Нека сега изброим клоновете, които не са обединени в master.

$ git клон - не е обединен

Изход

Стъпка 2.2: И накрая, нека изтрием не-обединен клон със следната команда:

$ git клон -d prepod

Ако се опитате да изтриете един от клоновете с незавършена работа, кажете “preprod” клон, git показва предупредително съобщение.

Изход

Сега, преди да ви кажа как можете да възстановите данните в тази статия в Git Reflog, позволете ми да ви кажа какво точно се случва, когато клонът бъде изтрит и при какви обстоятелства клонът може да бъде възстановен.

Как и кога клонът се изтрива?

Както знаем, че Git е a Разпределена система за контрол на версиите (DVCS), всяка машина с клонинг или копие на хранилището действа и двете възел и а хъб . Товапредполага, че всяка машина ще има свое собствено копие на целия код на хранилището и историята.Излишно е да казвам, че ще бъдете споделяне вашата работа с другите и издателство същото.

Следователно в такива сценарии може да има 3 случая, когато клон се изтрива в реалния сценарий с много участници, работещи по голям проект. Следните случаи могат да бъдат:

Случай 1 - Програмистът може да обедини или изтрие клона

Помислете за сценарий, при който разработчик обединява разклонението на обекта в основния клон локално и след това изтрива разклонението на обекта с помощта на git клон Команда с „- д ”Флаг, както се вижда на по-ранните екранни снимки.

Команда: ‘Git клон -d име_клон’

Също така може да се случи така, че разработчикът да реши да изтрие промените в клона и да реши да изтрие клона, без да го обединява с друг клон, използвайки следната команда:

Команда: ‘Git клон -D име_клон’

java string split regex множество разделители

С горната команда разработчикът епринудително изтрийте клона, заменящ предупреждението за git

$ git клон -D предпродажба

Изход

Забележка : Клонът „preprod“ вече няма да бъде изброен, когато стартирате командата „git клон“. И така, унашата работа, запазена в този клон, ще бъде загубена.

Случай 2 - Програмист изтрива клон в споделено хранилище

Помислете за сценарий, при който разработчик с достъп за четене / запис се опитва да изтрие принудително отдалечения клон отизползвайки командата ‘git push’ с флага ‘–delete’.

$ git push origin - Изтриване на бърза корекция

Изход

Отделно от това, може да има и случай, когато неоторизиран или злонамерен потребител принуждава да изтрие отдалечения клон.В такъв случай поддържащият ще може да възстанови изтрития клон „бърза корекция“ само ако разработчикътпреди това е проверил този клон. В този сценарий неговото локално хранилище все още ще има референтни дневници за него.

Ако поддържащият не може да възстанови клона, тогава собственикът на клона, който го е изтрил, трябва да се възстанови от своите локални релоги.

Случай 3 - Кук скрипт със супер привилегии изтрива клона

Това може да е рядък, но възможен сценарий, при който скриптът за закачане се задейства при определено събитие на git операция и принудително изтрива клоновете, които още не са обединени. Можешпомислете за това, че една от гореспоменатите команди е скрипт в скрипт скрипт с права на sudo.

Сега, след като знаете какво се случва, когато изтриете клона, нека продължим с тази статия за Git Reflog и да видим как да възстановим изгубен клон.

Възстановете изтрит клон с помощта на Git Reflog

Етап 1 : Журнали на историята на всички препратки

Вземете списък с всички регистрирани локални журнали за всички препратки („master“, „uat“ и „prepod“) в това хранилище.

отидете пререгистрирайте

Стъпка 2 : Идентифицирайте историческия печат

Както можете да посочите от горната снимка, Идентифициран идентификатор на ангажимент: e2225bb заедно с индекса на указателя HEAD: 4 е този, когато препродажба Клонът е създаден от текущия указател HEAD, сочещ към последната ви работа.

Стъпка 3 : Възстановете се

За да възстановите обратно ‘Препродажба ‘Клон използва командата‘Git checkout’, предаващ препратка към указател HEAD с индекс id - 4.Това е препратката към указателя, когато клонът „preprod“ е създаден с дълъг идентификатор на фиксиране, подчертан в изходната екранна снимка.

git checkout -b preprod HEAD @ {4}

Изход

И вуаля! ‘ препродажба ‘Клонът се възстановява обратно с целия ви изходен код.

ЗАБЕЛЕЖКА : Нека bповторно вземете командата ‘git checkout’, използвана по-горе, и ще ви помогне да разберете по-добре:

Командата ‘git checkout’ е свръхнатоварена команда (Също като всяка претоварена функция на Java). Това е частта, при която действителният клон се възстановява.

Тази единична команда първо проверява към по-ранния времеви отпечатък, посочен от Указател HEAD @ {4} и след това създава клон с името ‘preprod’, използвайки опцията “-b”, както и превключва вашата работна директория към новосъздадения клон.

Това предполага, че клонът ще бъде превключен от „master“ на „preprod“, както е посочено в изходния екран.Вече можете да го обедините с ‘master’ или ‘release’ клон според вашия модел на разклоняване.

Сега, след като знаете как да възстановите клон, нека ви кажа каква работа се възстановява при възстановяване на изтрит клон.

Каква работа се възстановява, когато изтритият клон се възстанови?

Файловете, които бяха скрити и записани в списъка със скривалища, ще бъдат възстановени обратно. Всички непроследени файлове ще бъдат загубени. Аз същоДобра идея е винаги да поставяте и ангажирате работата си или да ги скривате.

За да извлечете референтните файлове на даден клон или етикет, изпълнете командата - “git reflog”.

Пример: За да проверите регистрационните препратки само на клон ‘uat’, използвайте командата - “git reflog uat”.

Подкоманди Git Reflog

отидете да пререгистрирате

Команда за отваряне на страницата с ръководството

$ git reflog --help

Изход

отидете пререгистрирайте шоу

Показва регистрационните файлове на препратката, предоставена в командния ред.

git reflog show master @ {0}

отидете да пререгистрирате изтича

Тази команда се използва за подрязване на по-старите записи за пренаписване.

git reflog изтича

отидете да пререгистрирате Изтрий

Тази команда изтрива единични записи от историята на пренаписването.

git reflog изтриване

отидете да пререгистрирате съществува

функция за сортиране c ++

Тази команда проверява дали ref (клон или таг) има записи за история на дневника.

git reflog съществува

Освен гореспоменатите команди, командата „Git Reflog“ приема различни подкоманди и различни опции в зависимост от подкомандите, споменати по-горе. За по-нататъшно четене стартирайте “ git reflog –help ”От прозореца на терминала.

С това стигаме до края на тази статия за Git Reflog.Намерението на DevOps е да създаде по-качествен софтуер по-бързо и с по-голяма надеждност, като същевременно призовава за по-голяма комуникация и сътрудничество между екипите. Ако сте заинтригувани от тази статия, c по дяволите от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение за сертифициране на Edureka DevOps помага на обучаващите се да разберат какво е DevOps и да придобият опит в различни процеси и инструменти на DevOps като Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack и GIT за автоматизиране на множество стъпки в SDLC.

Имате въпрос към нас? Моля, споменете го в раздела за коментари на статията „Git Reflog” и ние ще се свържем с вас възможно най-скоро.