advanced git commands
Този урок изследва полезни Git команди като Git Stash, Git Reset, Git Cherry Pick, Git Bisect и обяснява как да интегрирате GitHub с Jira:
В предишните ни уроци от тази поредица видяхме повечето функции на GitHub.
В този урок ще разгледаме следното:
- Създаване на издания
- Интеграция с Atlassian Jira
- Най-често използваните Git команди за разработчици
- Git Stash
- Git Cherry Pick
- Git Reset
- Git Bisect
=> Погледнете тук ръководството за GitHub.
разлика между b дърво и b дърво
Какво ще научите:
- Създаване на издания
- Интеграция на GitHub с Jira
- Разширени Git команди за разработчици
- Заключение
- Препоръчително четене
Създаване на издания
Изданията в GitHub се използват за обединяване на вашия софтуер, добавяне на бележки и двоични файлове (файлове WAR, EAR, JAR), за да могат клиентите и хората да използват същото.
За да създадете издание, отидете на главната страница на хранилището и кликнете върху Пускания раздел под Управление на теми.
Кликнете върху Създайте нова версия.
Предоставете етикет и заглавие на изданието. Двоичните файлове също се добавят към изданието. След като приключите, кликнете върху Публикуване на издание.
Изданието вече е готово с изходния код и двоичните файлове.
Интеграция на GitHub с Jira
Един от важните аспекти на проследимостта е препращането към проблема с Jira с комитите в GitHub. GitHub може да бъде интегриран с Jira не само за справка с проблема, но и за създаване на клонове и искане за изтегляне от Jira.
Така че обикновено, след като разработчикът започне да работи върху задачата или грешките, клон се създава от него. Публикувайте разработката или разрешаването на грешки, може да се създаде заявка за изтегляне от Jira за обединяване с основната майстор клон. След това клонът, създаден от разработчика, може да бъде изтрит.
За да настроим интеграцията, използвахме приставка Git интеграция за Jira. Това е търговски плъгин. Приставката може да бъде изтеглена от тук
Инсталирайте приставката в Jira от Администратор -> Добавки.
След като приставката бъде инсталирана, отидете на Приложение -> Git хранилища и се свържете с GitHub.
Въведете потребителското име и паролата на GitHub. Щракнете Свържете .
Ще бъдат показани хранилищата, споменати за потребителския акаунт. Кликнете върху Импортиране на хранилища за да завършите настройката за интеграция.
GitHub се ангажира с изданието Jira
Като част от съобщението за фиксиране въведете, както е показано по-долу. Кликнете върху Ангажиране на промени .
Пример 1: По-долу е даден пример за Интелигентен ангажимент което позволява на разработчиците да извършват действия по проблемите на Jira от съобщението за фиксиране. Една такава команда е # коментар заедно с ключа Issue, който добавя коментара към проблема Jira, както е показано по-долу.
Разделът за коментари е актуализиран.
Пример 2: Присвояване на потребител и актуализиране на времето, прекарано като 4 часа.
Използвай # assign и # време команда за интелигентно фиксиране в съобщението за фиксиране
И двете действия са завършени.
Пример 3: Променете състоянието на изданието на В процес на изпълнение .
Създайте клон
Тъй като задачите и грешките са възложени на разработчиците, те трябва да започнат да работят по разработката. За това те създават клон за проблема, по който работят, извършват дейности по разработка и издигат искане за изтегляне, за да се слеят в главния клон.
В изданието Jira в долната част щракнете върху Създаване на клон.
Кликнете върху Създайте клон.
В GitHub направете промяна във файла в създадения по-горе клон и извършете същото.
След като разработката завърши, потребителят може да издигне заявка за изтегляне от Jira.
В долната част на изданието кликнете върху Създайте заявка за изтегляне.
Кликнете върху Създайте. Искането за изтегляне ще бъде показано като Отворено.
Следващата стъпка е да обедините заявката за изтегляне в GitHub.
Състоянието се актуализира съответно в Jira.
Разширени Git команди за разработчици
В този последен раздел ще разгледаме някои от често използваните Git команди за разработчици. Няма нищо общо с GitHub, но ще помогне на разработчиците, преди да придвижат промените към GitHub.
Git Stash
В повечето от сценариите на проекта, когато работите по нова функция или подобрение, изведнъж ще се наложи да работите по спешен дефект, който е докладван и е запушалка на шоуто. Тъй като сте в средата на новата си работа и не сте я завършили, няма смисъл да се ангажирате с промените, които са направени наполовина.
Затова е по-добре временно да спрете или запазите полуизвършената работа, да работите върху грешката и да се върнете да работите по новата функция или подобрение. Git stash предоставя решение на това. Можете лесно да превключвате контекста на бързото извършване на промени.
Пример 1 :Да приемем, че работите по задача, която ви е възложена и когато погледнете състоянието, това показва, че към момента не е проследено.
Изведнъж ви е възложена грешка с висок приоритет. По този начин трябва временно да запазим или скрием работата, по която се работи в момента.
Изпълнете следната команда.
git stash save “Съобщение”
В този момент работната директория е чиста. Могат да се правят всякакви нови ангажименти и ако има грешки, можете да превключите клона, за да работите по него и т.н.
Когато искате отново да приложите промените там, където сте оставили, използвайте командата.
git stash pop
Горната команда ще премахне скривалището от списъка и ще приложи последното запазено състояние.
Можете също да използвате:
git stash се прилага
Горната команда ще запази промените в скривалището и няма да ги премахне.
Сега промените се прилагат повторно и можете да извършите промените.
Пример 2: Запазете промените, превключете клона и обединете промените.
Направете промяната във файла Html в майстор промени в клонове и скривалища.
Следващото е да преминете към буболечка клон, правете промени и ангажирайте промени.
git checkout -b бъг
Направете промени във файла Html.
git commit -a -m “Фиксиран проблем с имейл”
Върнете се обратно на майстор разклонете се и приложете отново промените от скривалището.
Сега обединете от буболечка клон до майстор клон. Ангажирайте промените след сливането.
Пример 3: Работа с множество скривалища.
В локалното репо има 2 Html файла. Така че е възможно множество разработчици да работят по множество файлове и да скриват промени, ако е необходимо, за да работят по спешни заявки, които се появяват по пътя им, за да коригират промените.
Developer 1 работи върху hello.html, а Developer 2 работи върху index.html.
Програмист 1
Списъкът с скривалища има 1 запис сега.
Програмист 2
Списъкът с скривалища вече има 2 записа. Най-новото скривалище е първо в стека, което е скривалище @ {0}. Сега и двамата разработчици могат да направят спешно всички други ангажименти или да работят върху някой друг клон и след това да се върнат в майстор разклонете и приложите промените в скривалището.
За да приложите най-новото скривалище, можете просто да стартирате
git stash pop
За да приложите конкретно скривалище в стека, изпълнете следната команда.
git stash поп скривалище @ {1}
Нека приложим второто скривалище, което е скривалище @ {1}
По същия начин може да се приложи другото скривалище.
Git Cherry Pick
Днес разработчиците работят върху множество клонове като функция, подобрение, грешка и т.н.
Има ситуации, при които трябва да бъдат избрани само няколко конкретни фиксации и да не се обединява целият клон в друг клон. Това се нарича Cherry Pick. Този процес ви позволява произволно да изберете всеки Git ангажимент от другите клонове и да го добавите към текущата HEAD на работещото дърво.
Пример 1:
В локалното хранилище на git имаме следните 6 файла.
Един файл се изтрива say file5.txt.
Задайте промените.
Вижте дневника сега. File5.txt се изтрива.
И така, ние искаме да Cherry-Pick ангажирането, където сме добавили file5.txt. Трябва да намерим идентификатора на фиксиране на file5.tx и да изпълним командата.
git cherry-pick
В този случай идентификаторът на фиксиране при добавяне на file5.txt е a2f0124
File5.txt вече е възстановен. Ние избрахме ангажимента.
Пример 2:
Нека просто да модифицираме file6.txt и ангажирайте промените в майстор клон.
Погледнете втория ред в file6.txt където имейл адресът не е посочен правилно.
Създайте клон за грешка и отстранете проблема. Едновременно с това модифицирайте file5.txt, така че да имаме множество фиксирания в клона на грешките, но Cherry-Pick само ангажирането, извършено във file6.txt.
Файл 6, модифициран в буболечка клон.
Така че като цяло направихме промени в файл5 и файл6 в клона на Bug.
Нека сега се върнем към майстор клон и Cherry-Изберете ангажирането, направено само за file6.txt.
Както можете да видите, вместо да обединявате буболечка клон в майстор клон, ние току-що избрахме Cherry-Pick само конкретен ангажимент и приложихме в главния клон.
Git Reset
Git reset е мощна команда за отмяна на локални промени. Така че, за да премахнете сцената, се използват всички поетапни файлове, използвани тази команда.
Пример
Променете файл и го добавете към инсценирането. Нулирайте с помощта на командата, както е показано, когато поетапните промени са нестадийни.
Параметри на git нулиране команда.
–Мек: Този параметър ще насочи HEAD към друг ангажимент. Всички файлове се променят между оригиналната HEAD и фиксирането ще бъде поетапно. Работната директория е непокътната.
Погледнете текущото местоположение на HEAD.
Да се върнем 5 ангажимента в историята.
Повторно ангажирайте промените.
–Смесен: Опцията е подобна на мекия параметър. Обикновено, когато има някои лоши ангажименти, вие ги премахвате и поправяте по-късно и ги връщате обратно. Така че по същество трябва да добавим към индекса с помощта git add и тогава git commit. Промените са оставени в работещото дърво.
Да се върнем 2 ангажирания в историята и да видим, че файловете не са проследени.
Сега добавете файловете към етап и ангажирайте промените.
-твърд: Този параметър ще почива до точка, в която съществува определен файл. Промените няма да бъдат налични в работещото дърво.
Разглеждането на горния дневник позволява да се върнем към точката, в която е бил ангажиран само файл 1, т.е. последният запис.
Използвайки git reset –hard
Git Bisect
Намерете точния ангажимент, който е нарушил кода (В края на краищата всички ние сме хора). Често по време на тестване на приложението чуваме от нашите тестери, че има грешка или функцията е повредена и вие като разработчик ще кажете, че е работило миналата седмица. И така, какво се случи и защо се появи тази грешка?
Понякога промяната в другия код може да повлияе на функцията ви. Трябва да прекарате време в историята, където има много ангажименти, които отнемат много време и е трудно да се проследи коя промяна е причинила пробив на кода.
Git Bisect е командата за намиране на точния фиксиране при въвеждането на грешката. С Git bisect трябва да изберете две ангажименти, една добра и една лоша. Около половината път между двата фиксации ще бъде отметнато. Проверявате всеки коммит или лош, или добър, докато не бъде намерен коммитът, който е причинил повреда на грешката или кода.
Пример:
- Създайте ново локално хранилище на git и създайте файл, наречен index.html
- Първоначалното съдържание на файла, както е показано.
- Добавете към подреждане и се ангажирайте към хранилището.
- Създайте история на ангажименти, както е показано, за да можем да избираме между добри и лоши ангажименти. Сега, когато първоначалното фиксиране е направено, направете другите промени, както е показано, и ангажирайте същото. Като цяло ще направим 7 ангажименти.
Втора промяна
Трета промяна
Четвърта промяна
Пета промяна
Шеста промяна
Седма промяна
Нека спрем до тук. И така, имаме седем ангажименти.
Ако погледнете страницата Html, редовете след „Всички 4 събития ...“ са грешни и следователно документацията не е вярна. И така, трябва да намерим фиксацията там, където е била въведена грешката, за да можем да успокоим HEAD към този ангажимент.
Нека да разгледаме дневника и да разберем лошо и добър ангажимент.
Последният ангажимент не е правилен, така че може да бъде лош ангажимент. Ангажирането беше въведено след третия фиксиране, така че можем да имаме Трета промяна като доброто обвързване.
Процесът на бисектиране започва с git bisect start и завършва с нулиране на git bisect.
git bisect лошо // Тъй като последният коммит е лош. Няма нужда да предоставяте идентификатор на фиксиране.
git bisect добро
Вече можете да видите, че HEAD вече е между половината от лошите и добрите ангажименти.
Погледнете съдържанието на index.html и вижте дали има добър ангажимент. Ако не, тогава грешката все още не е намерена.
Всъщност не е, че грешката все още съществува. Последният ред е грешен. И така, ние пускаме git bisect bad ’. Все още има лош ангажимент и текущото съдържание не е приемливо.
Горното съдържание е правилно и приемливо.
Изпълнете ‘git log –oneline’ и ‘git bisect good’.
Така че Пета промяна беше първият лош ангажимент и наистина така. Грешката е идентифицирана.
Настоящото съдържание трябва да бъде в окончателната документация.
Тъй като е идентифициран лошият коммит, можете да информирате разработчика да коригира промените, които може да са за нулиране на главата до четвъртата промяна, която е последната добра фиксация.
Тичам нулиране на git bisect ’, За да приключи процеса.
Заключение
В този практически пример за GitHub се опитахме да обхванем всичко, върху което разработчикът ще трябва да работи, т.е.от гледна точка на контрола на версиите и проследяването.
В първите три урока от поредицата GitHub научихме за дейностите по контрол на версиите, създаване на хранилища, искане за изтегляне, клонове, прегледи на кодове, организации и екипи, разклоняване на хранилище, етикети, етапи, проблеми, дъски на проекти, уикита, издания, интеграция с Jira и някои често използвани Git команди за разработчици.
Искрено се надяваме, че всички разработчици ще намерят този практически подход за GitHub и командите Git полезни в техните проекти.
=> Прочетете серията Easy GitHub Training.
Препоръчително четене
- Урок за интеграция на GitLab Jira
- Команди на Unix: Основни и разширени команди на Unix с примери
- Интеграция на селен с GitHub с помощта на Eclipse
- Урок за интеграция на JIRA и SVN
- Git срещу GitHub: Разгледайте разликите с примери
- Урок за краставици селен: Интеграция на краставица Java Selenium WebDriver
- Урок за GitHub за разработчици | Как да използвам GitHub
- Урок за тръби на Unix: Тръби в програмирането на Unix