Розширені команди Git та підручник з інтеграції GitHub

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
  • Git Bisect

=> Погляньте на посібник GitHub тут.

запитання та відповіді на співбесіду для тестування pdf

Що ви дізнаєтесь:

• Створення випусків
• Інтеграція GitHub із Jira
  • GitHub фіксує випуск Jira
  • Створити гілку
• Розширені команди Git для розробників
  • Git Stash
  • Git Cherry Pick
  • Скидання Git
  • Git Bisect
• Висновок
• Рекомендована література

Створення випусків

Випуски в 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. Отже, цілком можливо, що кілька розробників працюватимуть над декількома файлами та зберігатимуть зміни, якщо це буде потрібно для роботи над терміновими запитами, які потрапляють на їх виправлення.

Розробник 1 працює на hello.html, а розробник 2 працює на index.html.

Розробник 1

Наразі в сховищі є 1 запис.

Розробник 2

Список схованки тепер містить 2 записи. Останній схованка є першим у стеку, який називається stash @ {0}. Тепер обидва розробники можуть терміново робити будь-які інші коміти або працювати над іншою гілкою, а потім повернутися до майстер гілку та застосувати зміни тайника.

Щоб застосувати останню схованку, ви можете просто запустити

git stash pop

Щоб застосувати певний тайник у стеці, виконайте наступну команду.

git stash pop stash @ {1}

Давайте застосуємо другий тайник, який є схованка @ {1}

Подібним чином можна застосувати інший схован.

Git Cherry Pick

Сьогодні розробники працюють над різними гілками, такими як функція, вдосконалення, помилка тощо.

Бувають ситуації, коли потрібно вибрати лише пару конкретних комітів, а не об’єднувати всю гілку в іншу гілку. Це називається Вишневий Збір. Цей процес дозволяє довільно вибрати будь-який коміт Git з інших гілок і додати його до поточної HEAD робочого дерева.

Приклад 1:

У локальному сховищі git ми маємо наступні 6 файлів.

Один файл видаляється, скажімо, 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 буде виконувати лише коміт, зроблений у файлі6.txt.

Файл 6, змінений у помилка відділення.

Отже, загалом ми внесли зміни до файл5 та файл6 у відділенні Буг.

Давайте повернемося до майстер branch і Cherry-Pick коміт, зроблений лише для file6.txt.

Як бачите, замість об'єднання помилка гілка в майстер , ми щойно вибрали Cherry-Picked лише певний коміт і застосували його у головній гілці.

Скидання Git

Git reset - це потужна команда для скасування локальних змін. Отже, для зняття сценічного сценарію використовуються всі інсценізовані файли.

Приклад

Змініть файл і додайте його до індексації. Скиньте налаштування за допомогою команди, як показано, коли поетапні зміни не виконуються.

Параметри Git скинути команди.

–Софт: Цей параметр вкаже HEAD на інший коміт. Всі файли змінюються між початковою HEAD і коміт буде здійснено. Робочий каталог цілий.

Подивіться на поточне місцезнаходження HEAD.

Повернемося до 5 комітів в історії.

Повторно внесіть зміни.

–Змішані: Опція схожа на параметр soft. Зазвичай, коли є якісь погані коміти, ви видаляєте їх, виправляєте це пізніше і повертаєте назад. Отже, по суті, нам потрібно додати до індексу використання git add і потім git коміт. Зміни залишені в робочому дереві.

Давайте повернемося до 2 фіксів в історії та побачимо, що файли не відстежуються.

Тепер додайте файли до індексації та зафіксуйте зміни.

–Твердий: Цей параметр буде обмежений до точки, де існував певний файл. Зміни будуть недоступні в робочому дереві.

Перегляд вищенаведеного журналу дозволяє повернутися до точки, де було здійснено лише файл 1, тобто останнього запису.

Використовуючи git reset –жорсткий

Git Bisect

Знайдіть точний коміт, який порушив код (Зрештою, ми всі люди). Часто під час тестування програми ми чуємо від наших тестувальників, що є помилка або функція порушена, і ви як розробник скажете, що вона працювала минулого тижня. Отже, що сталося і чому з’явилася ця помилка?

Іноді зміна іншого коду могла вплинути на вашу функцію. Вам доведеться витратити час, переглядаючи історію, де є багато комітів, що займає багато часу і важко відстежити, які зміни призвели до поломки коду.

Git Bisect - це команда знайти точний коміт, коли була введена помилка. За допомогою Git bisect вам потрібно вибрати два коміти, один хороший і один поганий. Приблизно на половині шляху між обома комітами буде перевірено. Ви перевіряєте кожну фіксацію як поганою, так і доброю, поки не буде знайдено коміт, який спричинив помилку або код

Приклад:

• Створіть нове локальне сховище git і створіть файл з назвою index.html
• Початковий вміст файлу, як показано.

• Додайте до постановки та зафіксуйте у сховищі.

• Створіть історію комітів, як показано, щоб ми могли вибирати між добрими та поганими комітами. Тепер, коли початкове комітування виконано, виконайте інші зміни, як показано, і виконайте те саме. Загалом ми зробимо 7 комітів.

Друга зміна

Третя зміна

Четверта зміна

П’ята зміна

Шоста зміна

Сьома зміна

Зупинимось тут. Отже, у нас сім комітів.

Якщо ви подивитесь на сторінку HTML, рядки після 'Усі 4 події ...' помиляються, і, отже, документація неправильна. Отже, нам потрібно знайти фіксацію, де була введена помилка, щоб ми могли спрямувати HEAD до цього коміту.

Давайте подивимося на журнал і з’ясуємо погано і хороший коміт.

Останній коміт неправильний, тому може бути поганим комітом. Фіксація була введена після третього коміту, тому ми можемо мати Третя зміна як добрий коміт.

Процес дроблення починається з git bisect start і закінчується на скидання бісект git - -.

git bisect погано // Оскільки останній коміт поганий. Не потрібно вводити ідентифікатор коміту.

git бісектрис хороший

Тепер ви можете бачити, що HEAD зараз знаходиться між половиною поганих і добрих комітів.

Подивіться на вміст index.html і переконайтеся, що є хороший коміт. Якщо ні, то помилка все ще не знайдена.

Не зовсім так, що помилка все ще існує. Останній рядок помилковий. Отже, ми запускаємо git bisect bad ’. Досі існує поганий коміт, а поточний вміст неприйнятний.

Вищевказаний зміст є правильним та прийнятним.

Запустіть «git log –oneline» та «git bisect good».

Отже, П’ята зміна було першим поганим комітом, і справді так. Помилка виявлена.

Поточний зміст повинен міститися в підсумковій документації.

Оскільки ідентифіковано поганий коміт, ви можете повідомити розробника про виправлення змін, які можуть полягати у перезавантаженні голови до четвертої зміни, яка була останньою доброю комітою.

Біжи скидання бісект git - - ’, Щоб закінчити процес.

Висновок

У цьому практичному праймері GitHub ми спробували охопити все, над чим розробнику потрібно було б працювати, тобто з точки зору контролю версій та відстеження.

У перших трьох підручниках серії GitHub ми дізналися про діяльність з управління версіями, створення сховищ, запит на витягування, гілки, огляди коду, організації та команди, розгалуження сховища, мітки, етапи, проблеми, дошки проектів, вікі, випуски, інтеграція за допомогою Jira та деяких часто використовуваних команд Git для розробників.

Ми щиро сподіваємось, що всі розробники знайдуть цей практичний підхід до GitHub та команд Git корисними у своїх проектах.

=> Прочитайте серію навчальних програм Easy GitHub.

Рекомендована література

• Підручник з інтеграції GitLab Jira
• Команди Unix: основні та вдосконалені команди Unix з прикладами
• Інтеграція селену з GitHub за допомогою Eclipse
• Підручник з інтеграції JIRA та SVN
• Git проти GitHub: Вивчіть відмінності на прикладах
• Підручник з огірка селену: інтеграція огірка Java Selenium WebDriver
• Підручник для розробників GitHub | Як користуватися GitHub
• Підручник з труб Unix: Труби в програмуванні Unix