Ако сте в подобна ситуация и не знаете каква промяна счупи кода или Кой от много сътрудници притежава това бъг / функция , тогава git bisect е вашият изход. И така, в тази статия за git bisect ще научите какgit bisect‘Команда идва спасяване при откриване на първия лош коммит, който въвежда грешката, използвайки алгоритъма за двоично търсене.
Темите, обхванати в тази статия, са както следва:
Защо да използвам git bisect?
Няма съмнение във факта, че сте склонни да създавате редица ангажименти за всяка незначителна промяна в . В такъв сценарий отстраняването на грешки в кода се превръща в досадна задача, тъй като трябва ръчно да се върнете назад във времето към всяка отделна ревизия на моментната снимка на проекта, за да тествате работния код и да откриете грешката. Сега това става още повече комплекс когато имате работа на други да проверявате без водеща точка, също така да поискате всеки да изчисти собствените си грешки също не звучи много осъществимо.
По пътя можете също така да създадете и отхвърлите редица клонове на „функция“ (или актуална корекция) в процеса и в крайна сметка да загубите време и усилия, докато се отклонявате от основната линия на развитие.
Така че, за да избегнете подобни сценарии, можете да използватеgit bisectкоманда за намиране на лошата ревизия на проекта (или моментна снимка) и в крайна сметка да я поправите сgit revertкоманда.
Как търси ‘git bisect’?
Тази команда бисекти (разделя) вашата история между добре и лошо ангажирам обхват. То насочва вашето текущ проект държава до a среден клас ангажирам моментална снимка. След това командата git bisect се премества всеки идентификатор на фиксиране между този диапазон докато пауза при всяка снимка, за да ви позволи тествайте кода . Ако грешката съществува, декларирате ангажимента като лошо, ако не като добре освен ако търсенето не приключи.
Синтаксис
git bisect
За да разберем по-добре git bisect, нека създадем проект, който разработва кода за просто приложение за навигация, което да се използва в кола.
Първоначална настройка на проекта
За да създадете проект, който разработва кода за просто приложение за навигация, което да се използва в автомобил, можете да изпълните следните стъпки:
Етап 1: Създайте нова директория във вашата папка $ HOME:
cd $ НАЧАЛО mkdir my_nav_app
Стъпка 2: Придвижете се до новата директория:
какво е функции в sql
cd $ my_nav_app
Стъпка 3: Клонирайте, за да изтеглите проекта от моята GitHub страница:
git clone https://github.com/divyabhushan/my_nav_app.git
Сега нека разберем директориите на проекта и оформлението на файловете, както е отпечатано от командата:ls -lTR
След това нека видим дневника на историята на проекта, за да видим ангажиментите, които направих, за да генерирам този код -
Например, проста команда на git log отпечатва подробно историята, но аз обичам да форматирам и персонализирам историята. По този начин, нека задайте име на псевдоним - ‘hist’ използвайки git псевдоним команда, както е показано по-долу:
git alias.hist 'log --pretty = format:'% C (жълто)% h% Creset% ad | % C (зелено)% s% Creset% C (червено)% d% Creset% C (синьо) [% an] '--graph --decorate --date = short'
Сега ще изпълня тази функция за отстраняване на грешки в отделен клон, за да не преча на основното развитие на клона на „master“. За да направите това, следвайте следния набор от команди:
- Създайте клон ‘dev’: [главен] $
git клон dev - Превключете към клон ‘dev’: $
git checkout dev - Избройте дневниците на историята: [dev] $
отидете история[Забележка: Използвана тук команда „псевдоним“]
Освен това подчертах последния известен добър коммит, който знам, в който моят скрипт работи добре с очакваните резултати от тестови случаи, тази снимка на фиксиране е маркирани като v1.0.
И така, сега, след като знаем последния си добър ангажимент, нека да продължим в тази статия на тема „git bisect“ и да тестваме приложението.
Тествайте приложението
Стартирайте скрипта като - $./scripts/myApplication.sh[тестване за първи път]
Ясно е, че сегашното ми състояние на проекта е в грешка и не съм сигурен каква промяна направих в кой ангажимент, който въведе тази промяна. И така, следващата в тази статия за git bisect, нека видим как да идентифицираме лошия коммит.
Идентифициране на лошия ангажимент
За да започнете да проверявате за лош ангажимент, следвайте стъпките по-долу:
- Стартирайте командата bisect :
git bisect start - Споменете лошия идентификатор на фиксиране:
git bisect лоша ГЛАВАилиgit bisect c5b3ca8 - Споменете последния известен идентификатор за добро обвързване:
git bisect добър v1.0илиgit bisect 93859d8
Това разделя историята на фиксиране на диапазона приблизително по средата между добрите и лошите ангажименти, което ни води до идентификатора на фиксиране: f61a7e8
Следователно командата е проверила версията на проекта, както е била в този идентификатор на фиксиране. Сега нека продължим и отново да тестваме нашето приложение.
Команда за стартиране на приложението : $./scripts/myApplication.sh[тестване втори път]
Тъй като приложението премина в този ангажимент този ангажимент със сигурност не е лошият ангажимент. И така, следва да информирате същото за командата bisect като - $git bisect добро
Сега това допълнително ще стесни резултата от търсенето до първата половина на диапазона, както е показано -
Тествайте отново приложението си - Команда: $./scripts/myApplication.sh[тестване трети път]
Така че, тъй като виждаме грешка, както по-горе, това е лош ангажимент.
Уведомете командата bisect, стартирайте $git bisect лошо
Това допълнително стеснява търсенето и ви отвежда до последната синя обградена средна ревизия: a6ac769
И така, тествам приложението си за последен път, използвайки същата команда: $./scripts/myApplication.sh[тестване четвърти път]
Сега, тъй като приложението отново се провали, все още е лош ангажимент. И така, нека изпълним следната команда:
Изпълнете командата: git bisect лошо
Намерен е лош ангажимент
Това завършва единствения останал последен коммит, който е лош-
Значи знаете, че тук се счупи кода. Какво следва?
Разберете какъв файл е имал грешката
В този случай изходът ви дава минимална информация за идентификатор на фиксиране , име на автора , и дата на автор заедно с съобщение за ангажиране и път това беше променено.
Ако искате да отстраните грешки допълнително, трябва Прочети на фиксиране на обект id .
Команда: git show a6ac76994b3f6c7519204f910fc787b7928cf8ef
system.exit (0) може да се използва за прекратяване на програмата.
Това ще прочете обекта за фиксиране и ще отпечата съобщението в дневника и текстовата разлика
Можете също така да използвате командата ‘git вина’, за да анализирате как и в кой коммит е променен всеки ред от кой автор, изпълнете командата като:git виновния код / develo_nav.sh
Спрете търсенето
За да спрете търсенето, използвайте следната команда:
Команда: нулиране на git bisect
По този начин процесът на bisection се спира и вие се връщате на клона, от който сте започнали търсенето. Следващата стъпка е да поправите или отстраните грешки в кода.
Как да поправя / отстранява грешки в кода?
Е, има няколко решения, които можете да направите, за да поправите текущото състояние на проекта сега, след като сте идентифицирали ангажимента, донесъл грешката на първо място.
Ако обаче променяте фиксиране на a споделено хранилище най-добре е да връщане промяната с помощта на git revert ‘Команда.
Задача: Върнете промените, направени от споменатия лош коммит
Команда: git revert a6ac769
В резултат на това връщането на промените, направени от този ангажимент, направи 2 неща:
- Той изтри последните 3 добавени реда (обозначени в зелено) и добави обратно изтрития ред (обозначен в червено). (обратна страна на a6ac769)
- Създаде допълнителен ангажимент с информацията за връщане на съобщението
„Командата за връщане също улеснява проследяването на промяната, която сте върнали от първоначалния фиксиране“
Използвай ‘Шоу’ команда отново, за да прочетете идентификатора на обекта, като so-
Команда: git show 801f029
Сега продължете напред и тествайте приложението. Ще се изпълни правилно.
Команда: $./scripts/myApplication.sh
За разлика от това, ако искате да премахнете лошия ангажимент от историята:
Можете да използвате „
git нулиране‘Команда с„--трудноОпция (макар и да не се препоръчва в споделено хранилище).Вижте по-ранна версия на един файл, като използвате „
git плащане‘Команда с‘-‘Опция.
Трябва да се отбележи, че това ще направи промени само във вашето локално хранилище, докато не избутате промените в отдалечено хранилище. Тъй като някои промени създават нов идентификатор на обект за фиксиране, както в нашия случай по-горе, в такива случаи нормално избутване към отдалеченото хранилище се отхвърля, тъй като историята би се разминала. Трябва да използвате „ git push ‘Команда с‘- сила‘Опция.
Актуализирайте ‘master’ клон
Докато коригирах грешката в моя клон ‘dev’, вече мога да обединя тази промяна с клон ‘master’ също-
- превключете на „master“, команда:
git checkout master - изтеглете последните актуализации от ‘origin / master’ в ‘master’, команда:
git pull произход - обединете промените на ‘dev’, команда:
git merge гигант
Вашето сливане обаче може да генерира конфликти, ако има повече фиксирания от отдалеченото хранилище. Разрешете конфликти и продължете със сливането.
И накрая, натиснете само стабилните фиксиращи клонове „master“ към отдалеченото хранилище, докато извършвате мръсната си работа (грешка, функции, подобрения) само върху клоновете на функции като „dev“ в този пример.
Освен това е най-добре да се възприеме логическо стратегия за разклоняване за да рационализирате и защитите вашия git работен процес.
За да обобщим, „git bisect“ е удобна и полезна команда, която бързо идентифицират на идентификатор на ангажимент че въведени да се грешка във вашия работещ код с помощта на обширна двоично търсене от логично разделяне регистрационните дневници по средата между добре и лошо ангажирам обхват . В заключение научихте откривам дефектното ангажиране и връщане промяната, направена от него.
В допълнение към подкомандите „добър“ и „лош“ можете също да използвате термини като нов и стар, за да опишете състоянието на ревизията. Можете да стартирате командата няколко пъти, като предавате различни подкоманди и ревизирате / фиксирате идентификатори, за да идентифицирате различни идентификатори на commit (she-1). Като алтернатива може да се изпълни и автоматичен тестов скрипт за изграждане на счупения код с помощта на тази команда. Също така намерете подробно описание на тази команда, като изпълнитеgit bisect --helpна терминала. И така, хора с това стигнахме до края на тази статия за Git Bisect.
Намерението на DevOps е да създаде по-качествен софтуер по-бързо и с по-голяма надеждност, като същевременно призовава за по-голяма комуникация и сътрудничество между екипите. Ако сте заинтригувани от тази статия, c по дяволите от Edureka, доверена компания за онлайн обучение с мрежа от над 250 000 доволни учащи, разпространени по целия свят. Курсът за обучение за сертифициране на Edureka DevOps помага на обучаващите се да разберат какво е DevOps и да придобият опит в различни процеси и инструменти на DevOps като Puppet, Jenkins, Nagios, Ansible, Chef, Saltstack и GIT за автоматизиране на множество стъпки в SDLC.
Имате въпрос към нас? Моля, споменете го в раздела за коментари на статията „Git Bisect“ и ние ще се свържем с вас възможно най-скоро.