40 найкращих запитань та відповідей на інтерв’ю GIT у 2021 році

top 40 git interview questions

Найпопулярніші запитання для інтерв’ю GIT із відповідями та прикладами:

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

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

Давайте розпочнемо!!

Найчастіші запитання щодо інтерв’ю у GIT

Нижче наведено деякі найпоширеніші запитання щодо співбесіди з GIT.

Q # 1) Що таке Git?

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

Git є безкоштовним і відкритим. Його можна використовувати майже для будь-якого типу проекту, будь то невеликий чи великий за розміром. Git відомий своєю великою швидкістю та ефективністю. Репозиторії Git дуже легко знайти і отримати до них доступ. Завдяки певним особливостям, Git є надзвичайно гнучким, безпечним та сумісним із вашою системою.

Q # 2) Що таке розподілена система контролю версій?

Відповідь: Розподілений VCS - це система, яка не залежить від центрального сервера, щоб зберігати файл проекту та всі його версії. У розподіленому VCS кожен співавтор або розробник отримує локальну копію основного сховища, і це називається клоном.

(зображення джерело )

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

За допомогою операції витягування розробник може оновити свій локальний репозиторій останніми змінами з центрального сервера. Використовуючи операцію push, вони можуть надсилати свої зміни з локального сховища на центральний сервер.

Q # 3) Хто створив Git?

Відповідь: Git був створений Лінусом Торвальдсом у 2005 році на шляху розробки ядра Linux.

Q # 4) Яка мова використовується в Git?

Відповідь: C - основна мова програмування, на якій написано Git. Мова C робить Git швидким, уникаючи накладних витрат на виконання, пов'язаних з іншими мовами програмування високого рівня.

Q # 5) Які переваги / основні особливості Git?

Відповідь: Нижче перераховані різні ф їжі Git.

(i) Безкоштовне та відкрите джерело:

Git видається за ліцензією GPL (General Public License) із відкритим кодом. Вам не потрібно нічого платити за використання Git.

Це абсолютно безкоштовно. Оскільки він відкритий, ви можете змінити вихідний код відповідно до своїх потреб.

(ii) Швидкість:

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

Git написаний на мові C, що є основною мовою програмування, яка уникає накладних витрат під час виконання, пов'язаних з іншими мовами високого рівня.

(iii) Масштабована:

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

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

(iv) Надійний:

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

(v) Захищений:

Git використовує SHA1 (функцію безпечного хешування) для іменування та ідентифікації об'єктів у своєму сховищі. Кожен артефакт та коміт підсумовуються та відновлюються за допомогою контрольної суми під час оформлення замовлення.

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

(vi) Економічний:

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

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

(vii) Підтримує нелінійний розвиток:

Git забезпечує швидке розгалуження та злиття та містить конкретні інструменти для передбачення та проходження нелінійної історії розвитку. Основне поняття в Git полягає в тому, що зміна буде об'єднуватися частіше, ніж вона написана, оскільки надсилається різним рецензентам.

Git Branches надзвичайно легкі. Гілка в Git стосується лише одного коміту. Повну структуру гілки можна створити за допомогою батьківських комітів.

(viii) Просте розгалуження:

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

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

(ix) Розподілений розвиток:

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

(x) Сумісність разом із існуючими системами або протоколом:

Репозиторії можуть публікуватися через HTTP, FTP або протокол Git поверх звичайного сокета або ssh.

Q # 6) Як створити сховище в Git?

Відповідь: Щоб створити сховище, вам потрібно створити каталог проекту, якщо він ще не існує, а потім просто виконати команду “ git init '. Виконуючи цю команду, у каталозі проекту буде створений каталог .git, тобто тепер ваш каталог проекту перетворений на сховище Git.

Q # 7) Що таке каталог .git?

Відповідь: Як тільки ви створите сховище, ви знайдете в ньому каталог .git. Цей каталог .git містить усі метадані сховища та веде відстеження всіх змін, внесених до файлів у вашому сховищі, зберігаючи історію комітів.

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

Q # 8) Що станеться, якщо каталог .git буде видалено?

Відповідь: Якщо каталог .git / буде видалено, ви втратите історію свого проекту. Сховище більше не буде знаходитися під контролем версій.

Q # 9) Яка команда використовується для написання повідомлення коміту в Git?

Відповідь: Команда, яка використовується для передачі повідомлення до коміту git: git commit -m “повідомлення про коміт”. Прапор м використовується для передачі повідомлення коміту.

Q # 10) Що таке відкрите сховище Git? Чим він відрізняється від стандартного / не оголеного сховища Git?

Відповідь: Сховища, які створюються через git init команди - це стандартні / не оголені сховища Git.

У папці верхнього рівня такого сховища ви знайдете дві речі:

1. Підкаталог .git, що зберігає всі метадані та відстежує історію вашого репо.
2. Працююче дерево.

Сховища, які створені за допомогою git init - голий команди відомі як голі сховища Git. В основному вони використовуються для обміну. Вони не містять жодного робочого дерева. Вони зберігають історію ревізій git вашого сховища у кореневій папці, а не містять її у підпапці .git.

Він просто містить відкриті дані сховища. Цим просто відкрите сховище Git відрізняється від стандартного сховища Git. Крім того, голе сховище не має пульта дистанційного керування за замовчуванням походження сховище, оскільки воно служить сховищем джерела для кількох віддалених користувачів.

Оскільки оголене сховище не містить жодної робочої області, файл git push і git pull команди не працюють через оголене репо. Вам не потрібно вносити будь-які зміни до простого репо.

Q # 11) Згадайте деякі послуги хостингу Git Repository.

Відповідь:

• Github
• Пікакод
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• Стартова площадка
• Виконати
• Бобовий стебло
• Це виглядає як

Q # 12) Назвіть деякі основні операції в Git.

Відповідь: Деякі основні операції в Git включають:

• Ініціалізувати
• Додати
• Здійснити
• Натисніть
• Потягніть

Q # 13) Назвіть деякі розширені операції в Git.

Відповідь: Деякі розширені операції в Git:

• Розгалуження
• Злиття
• Перебазування

Q # 14) Як ви будете розрізняти Git та SVN?

Відповідь: Git - це розподілений контроль версій, тоді як SVN централізований. Це призводить до багатьох відмінностей між ними з точки зору їх особливостей та функціональних можливостей.

Q # 15) Як ви будете розрізняти Git та GitHub?

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

Основними цілями Git є швидкість, цілісність даних, забезпечення підтримки розподілених, нелінійних робочих процесів. Git встановлюється та підтримується на локальній машині замість хмари.

GitHub - це хмарний сервіс хостингу сховищ Git, який об'єднує команди. Він надає веб-графічний інтерфейс, а також забезпечує контроль доступу та безліч функцій співпраці, основні інструменти управління завданнями для кожного проекту.

Крім того, GitHub - це відкритий код, тобто код зберігається на централізованому сервері і може отримати до нього доступ кожен.

Q # 16) Що таке конфлікт у Git та як його вирішити?

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

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

У таких випадках вам потрібна ваша допомога, щоб вирішити, який код включити, а який відхилити під час остаточного злиття.

Конфлікт злиття може статися під час злиття гілки, перебазування гілки або вибору комміту. Після виявлення конфлікту Git виділяє конфліктну область і просить вас її вирішити. Після вирішення конфлікту можна продовжувати об’єднання.

Виконайте наведені нижче кроки, щоб вирішити конфлікт злиття між змінами рядків:

1. Відкрийте Git Bash (командний рядок Git).
2. Використовуйте CD команда перейти до локального сховища Git, що має конфлікт злиття.
3. Використовувати git статус команда для створення списку файлів, на які впливає конфлікт злиття.
4. Відкрийте текстовий редактор, який ви використовуєте, і перейдіть до файлу, що має конфлікти злиття.
5. Щоб побачити початок конфлікту злиття у вашому файлі, знайдіть у документі маркер конфлікту<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> НАЗВА ФІЛІЇ.
6. Виберіть, якщо вам потрібно зберегти лише зміни вашої гілки, просто збережіть зміни іншої гілки або внесіть нові зміни, які можуть включати зміни з двох гілок. Видаліть маркери конфлікту<<<<<<>>>>>> та внесіть необхідні зміни в остаточному об’єднанні.
7. Використовуйте git додає. команда додати або поетапно внести зміни.
8. Нарешті, використовуйте git commit -m “повідомлення” команда для внесення змін із коментарем.

Щоб вирішити конфлікт видаленого файлу, потрібно виконати наведені нижче дії.

1. Відкрийте Git Bash (командний рядок Git).
2. Використовуйте CD команда перейти до локального сховища Git, що має конфлікт злиття.
3. Використовувати git статус команда для створення списку файлів, на які впливає конфлікт злиття.
4. Відкрийте текстовий редактор, який ви використовуєте, і перейдіть до файлу, що має конфлікти злиття.
5. Виберіть, чи хочете ви зберегти вилучений файл. Ви можете перевірити останні зміни, зроблені у видаленому файлі, у своєму текстовому редакторі.
6. Використовуйте git add команда для додавання видаленого файлу назад до сховища. Або, Використовуйте йди rm команда для видалення файлу з вашого сховища.
7. Нарешті, використовуйте git commit -m “повідомлення” команда для внесення змін із коментарем.

Q # 17) Як ви виправите Broken commit?

Відповідь: Щоб виправити непрацюючий коміт або змінити останній коміт, найзручнішим методом є використання команди “ git commit -amend ’ .

Це дозволяє поєднувати поетапні зміни з попереднім комітом як альтернативу для створення абсолютно нового коміту. Це замінює найновіший коміт зміненим комітом.

(зображення джерело )

За допомогою цієї команди ви також можете редагувати попереднє повідомлення коміту, не змінюючи його знімок.

Q # 18) Яка користь git instaweb?

Відповідь: Це сценарій, за допомогою якого ви можете миттєво переглядати робоче сховище Git у веб-браузері.

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

Q # 19) Що таке git is-tree?

Відповідь: 'Git is-tree' означає дерево-об'єкт, що включає режим та ім'я всіх елементів, а також значення SHA-1 BLOB-масиву або дерева.

Q # 20) Чи є спосіб повернути git-коміт, який вже було просунуто та оприлюднено?

Відповідь: Так, для виправлення чи скасування поганого коміту існує два підходи, які можна використовувати на основі сценарію.

Вони є:

1. Дуже очевидний спосіб - це зробити новий комміт, де ви видалите пошкоджений файл або виправити помилки в ньому. Закінчивши, ви можете перенести його у віддалене сховище.
2. Інший підхід полягає у створенні нового коміту, щоб скасувати всі зміни, зроблені в попередньому поганому коміті. Це можна зробити за допомогою команди git revert - “ git revert '

Q # 21) Як ви будете розрізняти git pull та git fetch?

Відповідь: Git pull Команда витягує всі нові коміти з певної гілки в центральному сховищі та оновлює цільову гілку у вашому локальному сховищі.

Git fetch також націлений на одне і те ж, проте його основна функціональність дещо інша. Коли ви робите git-вибірку, усі нові коміти з певної гілки будуть витягнуті до вашого центрального сховища, а ці зміни будуть збережені в новій гілці у вашому локальному сховищі. Це називається отриманою гілкою.

Якщо ви хочете побачити ці зміни у вашій цільовій гілці, вам потрібно виконати a перейти злиття після git fetch. Цільова гілка буде оновлена ​​з останніми змінами лише після об’єднання її з отриманою гілкою.

Отже, git pull оновлює локальну гілку з віддаленою версією, тоді як git fetch не змінює безпосередньо вашу власну локальну гілку або робочу копію під посилання / голови. Git fetch можна використовувати для оновлення ваших гілок віддаленого відстеження під посилання / пульти //.

Простими словами git pull дорівнює git fetch з наступним злиттям git .

Q # 22) Яка користь області Staging або індексації в Git?

Відповідь: З точки зору Git, є три області, де можна зберігати зміни у файлі, тобто робочий каталог, проміжний простір та сховище.

Спочатку ви вносите зміни до робочого каталогу проекту, що зберігається у файловій системі комп’ютера. Усі зміни залишаються тут, поки ви не додасте їх до проміжної області, яка називається етапною областю.

Ви можете виконати зміни, виконавши їх git add. команди. Ця інтерактивна область дає вам попередній перегляд наступного коміту та, в основному, дозволяє вам точно налаштувати свої коміти. Ви можете додавати або видаляти зміни в проміжній області, поки не будете задоволені версією, яку збираєтеся зробити.

Після того, як ви підтвердите свої зміни та вийдете зі сцени, що змінилася, ви зможете нарешті внести зміни. Після фіксації вони переходять до локального сховища, тобто до каталогу .git / objects.

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

Ви можете вибрати файл і натиснути на «етап змінено», після чого він буде переміщений в інтерактивну область. Наприклад , файл hello.txt присутній у стадії зміни (буде здійснено) області. Ви можете перевірити свої зміни, а потім здійснити реєстрацію, після чого виконайте коміт.

Індексація також називається індексуванням, оскільки git підтримує файл індексу для відстеження змін у вашому файлі в цих трьох областях. Наразі індексовані файли знаходяться у вашому індексі.

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

Q # 23) Що таке Git Stash?

Відповідь: Схованка GIT фіксує поточний стан робочого каталогу та індексу та зберігає його у стеці для подальшого використання. Він повертає незафіксовані зміни (як поетапні, так і нестадійні) з вашого робочого каталогу і повертає вам чисте робоче дерево.

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

Це корисно при швидкому переключенні контексту, коли ви знаходитесь посеред шляху зміни коду, який ви не хочете виконувати чи скасовувати прямо зараз, і у вас є над чим ще працювати. Команда для використання - git stash.

Q # 24) Що таке крапля Git Stash?

Відповідь: Коли вам більше не потрібна певна схованка, ви можете видалити її, виконавши команда git stash drop . Якщо ви хочете видалити всі схованки за один раз із сховища, тоді ви можете запустити команда git stash clear .

Q # 25) Що таке Git stash apply? Чим він відрізняється від Git stash pop?

Відповідь: Обидві команди використовуються для повторного застосування ваших схованих змін і початку роботи з того місця, де ви залишили.

В git stash застосувати команди, зміни будуть повторно застосовані до вашої робочої копії, а також зберігатимуться в схованці. Цю команду можна використовувати, коли ви хочете застосувати однакові сховані зміни до декількох гілок.

В git stash pop команди, зміни видаляються із схованки та повторно застосовуються до робочої копії.

Q # 26) Для чого використовується команда git clone?

Відповідь: клон git команда створює копію існуючого центрального сховища Git на вашій локальній машині.

Q # 27) Коли використовується команда git config?

Відповідь: git config Команда використовується для встановлення параметрів конфігурації для вашої інсталяції Git.

Наприклад, після завантаження Git вам потрібно використовувати команди налаштування нижче, щоб встановити ім'я користувача та зафіксувати адресу електронної пошти в Git відповідно:

$ git config –global user.name “”

$ git config –global user.email “”

Java, як створити масив об'єктів

Отже, в основному такі речі, як поведінка сховища, інформація про користувача та налаштування можна налаштувати за допомогою цієї команди.

Q # 28) Як ви визначите, якщо гілка вже об’єднана в master?

Відповідь:

Виконуючи наведені нижче команди, ви можете дізнатись про стан злиття гілок:

1. git гілка - об'єднаний майстер: Тут буде перераховано всі гілки, які були перейменовані в master.
2. гілка git - об'єднана: Тут буде перераховано всі гілки, об’єднані в HEAD.
3. гілка git –не об’єднана: Тут буде перелічено всі гілки, які ще не об’єднані.

За замовчуванням ця команда повідомляє про стан злиття лише локальних гілок. Якщо ви хочете знати як про місцевий, так і про віддалений стан злиття гілок, тоді можете скористатися -до прапор. Якщо ви хочете перевірити лише віддалені гілки, тоді ви можете використовувати -r прапор.

Q # 29) Що таке хуки в Git?

Відповідь: Git хуки - це певні сценарії, які Git запускає до або після такої події, як коміт, натискання, оновлення або отримання. Ви знайдете папку 'хуки' всередині каталогу .git у вашому локальному сховищі. Тут ви знайдете вбудовані сценарії до фіксації, після фіксації, попереднього натискання, після натискання.

Ці сценарії виконуються локально до або після настання події. Ви також можете модифікувати ці сценарії відповідно до своїх потреб, і Git виконає сценарій, коли настане ця конкретна подія.

Q # 30) Яка користь від git fork? Чим форк відрізняється від клонування?

Відповідь: Розгалужити проект означає створити віддалену копію оригінального сховища на стороні сервера. Ви можете перейменувати цю копію та розпочати новий проект навколо цього, не впливаючи на оригінальний проект. Форк - це не основне поняття Git.

Операція форка використовується робочим процесом Git, і ця ідея існує довше для вільного програмного забезпечення з відкритим кодом, такого як GitHub. Як правило, після того, як ви роздвоїли проект, ви рідко знову будете брати участь у батьківському проекті.

Наприклад, OpenBSD - це Unix-подібна операційна система з відкритим кодом, яка була розроблена форкінгом NetBSD, яка є ще однією Unix-подібною ОС з відкритим кодом.

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

У роздвоєній копії всі основні дані, такі як коди та файли, копіюються з оригінального сховища, однак гілки, запити на витягування та інші функції не копіюються. Forking - ідеальний спосіб співпраці з відкритим кодом.

Клонування - це, по суті, концепція Git. Клон - це локальна копія будь-якого віддаленого сховища. Коли ми клонуємо сховище, все вихідне сховище разом із його історією та гілками копіюється на нашу локальну машину.

На відміну від форкінгу, між клонованим сховищем та оригінальним віддаленим сховищем немає прямого зв'язку. Якщо ви хочете зробити запити на витягування і перейти до початкового проекту, вам слід додати себе як співавтора в оригінальному сховищі.

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

Q # 31) Як ви дізнаєтесь, що всі файли було змінено в певному коміті Git?

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

git diff-tree -r {хеш}

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

Ви також можете скористатися наведеною нижче командою:

git diff-tree –no-commit-id –name-only -r {хеш}

–No-commit-id буде перенавчати хеш-номери комітів, які надходять у вихідні дані. Тоді як -name виключає шляхи до файлів і надає лише імена файлів у вихідних даних.

Q # 32) У чому різниця між git checkout (назва гілки) та git checkout -b (назва гілки)?

Відповідь: Команда git checkout (назва гілки) переключиться з однієї гілки на іншу.

Команда git checkout -b (назва гілки) створить нову гілку, а також переключиться на неї.

Q # 33) Що таке SubGit?

Відповідь: SubGit - це інструмент, який використовується для SVN to Git Migration. Він розроблений компанією під назвою TMate. Він перетворює сховища SVN у Git і дозволяє одночасно працювати над обома системами. Він автоматично синхронізує SVN з Git.

(зображення джерело )

Ви можете створити SVN || дзеркало Git за допомогою цього інструменту. SubGit слід встановити на вашому сервері Git. Він виявить усі налаштування вашого віддаленого сховища SVN, включаючи версії SVN, гілки та теги, і перетворює їх у коміти Git.

Він також зберігає історію, включаючи відстеження даних злиття.

Q # 34) Чи можете ви відновити видалену гілку в Git?

Відповідь: Так, ти можеш. Щоб відновити видалену гілку, ви повинні знати SHA з верхньої частини голови. SHA або хеш - це унікальний ідентифікатор, який Git створює при кожній операції.

Коли ви видаляєте гілку, на терміналі відображається SHA:

Видалено гілку (було)

Ви можете використати наведену нижче команду для відновлення видаленої гілки:

git checkout -b

Якщо ви не знаєте SHA для коміту на кінчику вашої гілки, спершу можете використовувати піти переробляти команда, щоб дізнатися значення SHA, а потім застосувати вищезазначену команду перевірки, щоб відновити свою гілку.

Q # 35) Що таке git розл команда? Чим він відрізняється від git статус?

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

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

Q # 36) Що містить об'єкт коміту?

Відповідь: Об'єкт коміту містить хеш-об'єкт дерева верхнього рівня, хеш батьківського коміту (якщо такий є), інформацію про автора та комітети, дату коміту та повідомлення коміту.

Ви можете переглянути це через git log команди.

Приклад:

(зображення джерело )

Q # 37) Що таке git cherry-pick? У яких сценаріях можна використовувати git cherry-pick?

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

git cherry-pick commitSha - команда, що використовується для збору вишні. commitSha - посилання на коміт.

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

Він також може бути використаний у співпраці команд. Можуть існувати сценарії, коли один і той самий код потрібно спільно використовувати між двома компонентами продукту. У цьому випадку, якщо один розробник вже написав цей код, то інший може вибрати той самий.

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

Q # 38) Для чого використовується 'git reset'? Який режим за замовчуванням для цієї команди?

Відповідь: Git скинуто це потужна команда для скасування локальних змін стану репозиторію Git. Ця команда скидає поточну HEAD до вказаного етапу.

Він скидає як індекс, так і робочий каталог до стану вашого останнього коміту. Git reset має три режими, тобто м'який, жорсткий та змішаний. Режим роботи за замовчуванням змішаний.

Q # 39) Яка різниця між 'HEAD', 'working tree' та 'index'?

Відповідь: Робоче дерево або робоча область - це каталог, що містить вихідні файли, над якими ви зараз працюєте.

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

Цей файл присутній у /.git/index. HEAD - це посилання або вказівник на останній коміт у поточній гілці оформлення замовлення.

Q # 40) Яка різниця між перебазуванням та об’єднанням? Коли слід перебазувати, а коли об’єднати?

Відповідь: Команди rebase і merge використовуються для інтеграції змін від однієї гілки до іншої, але різним чином.

Як видно з двох зображень нижче, припустимо, у вас є коміти (це перед об’єднанням / перебазуванням). Після злиття ви отримаєте результат у вигляді комбінації комітів. Він пов'язує історії обох гілок і створює нове 'об'єднання коміту' у гілці об'єктів.

З іншого боку, перебазування перемістить всю гілку об’єкта, починаючи з кінця основної гілки.

(зображення джерело )

Комісії будуть виглядати так:

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

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

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

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

Q # 41) Який синтаксис для перебазування?

Відповідь: Синтаксис команди rebase є git rebase (new-commit)

Q # 42) Як ви видалите файл із Git, фактично не видаляючи його з вашої локальної файлової системи?

Відповідь: Ви можете використовувати для цього опцію 'кешоване':

git rm -rf –кешовані $ FILES

Ця команда видалить файли з вашого сховища, не видаляючи їх з вашого диска.

Q # 43) Яка загальна схема розгалуження в Git?

Відповідь: Загальна схема розгалуження базується на git-потоці. Він має дві основні галузі, тобто освоєння та розвиток.

• Головна гілка містить виробничий код. Весь код розробки в певний момент часу об'єднується у головну гілку.
• Гілка розробки містить попередній код виробництва. Після завершення функцій вони об’єднуються в головну гілку, як правило, через конвеєр CI / CD.

Ця модель також має деякі допоміжні гілки, які використовуються під час циклу розробки:

• Основні галузі / Тематичні галузі: Вони використовуються для розробки нових функцій для майбутніх випусків. Він може відійти від гілки розробки і повинен бути об'єднаний назад у гілку розробки. Як правило, ці гілки існують лише у сховищах розробників, а не за походженням.
• Галузі виправлень: Вони використовуються для незапланованого випуску, коли потрібно негайно виправити будь-яку критичну помилку у версії live prod. Вони можуть відгалужуватися від ведучого і повинні бути об'єднані назад у розробку та освоєння.
• Галузі випуску: Вони використовуються для підготовки нового виробничого випуску. Гілка випуску дозволяє виправити незначні помилки та підготувати метадані до випуску. Вони можуть відійти від розвитку, і їх слід знову об'єднати в майстер і розвивати.

Висновок

Ми пройшли через важливі питання, які зазвичай задаються під час інтерв’ю Git у цьому посібнику.

Це не тільки допоможе вам підготуватися до майбутніх співбесід, але також пояснить ваші концепції Git.

Все найкраще для Вашого інтерв’ю!

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

• Запитання та відповіді на інтерв’ю
• Деякі цікаві запитання щодо тестування програмного забезпечення
• Найкращі 40 програмних запитань та відповідей на програмування
• 40 найкращих запитань та відповідей на інтерв’ю J2EE, які слід прочитати
• Запитання та відповіді на інтерв’ю для тестування ETL
• 20+ найбільш часто задаваних питань та відповідей на співбесіду
• Найпопулярніші запитання для інтерв’ю щодо форм та звітів Oracle
• Деякі хитрі ручні тестування Питання та відповіді