- git --v
- git --version
- git --option
- git --current
- git remote add new
- git remote add origin
- git remote new origin
- git remote origin
git reset --hard HEAD~5
git merge --squash HEAD@{1}
- Скидають HEAD до п’ятого коміту в репозиторії, а потім зливаються з master гілкою.
- HEAD поточної гілки скидається назад на п’ять комітів, потім попередні коміти стискаються в один коміт.
- Видаляють останні п'ять комітів.
- Об’єднують останні п’ять комітів у нову гілку.
Пояснення:
git reset --hard HEAD~5
скидає поточну гілку до 5 коміту безпосередньо перед останніми (перегляньтеman gitrevisions
, щоб дізнатися більше про цю нотацію та інші цікаві альтернативи, такі якHEAD@{2 days ago}
). Оскільки це апаратне скидання, воно також перезаписує всі зміни в робочому дереві. Перегляньтеman git-reset
.git merge --squash HEAD@{1}
HEAD@{1} – це місце, де була гілка перед попередньою командою (ще раз див.man gitrevisions
). Ця команда встановлює стан індексу таким, яким він був би після злиття з цим комітом. Ця вся операція може бути засобом щоб взяти 5 комітів з гілки feature, і стиснути їх до одного, значущого коміту.
Q4. Ваш поточний проект має кілька гілок: main, beta та push-notifications. Ви щойно завершили роботу над функцією у гілці push-notifications і хочете закріпити зміни для beta. Як ви можете цього досягти?
- Перемкнутися на гілку push-notifications і запустити git merge beta
- Перемкнутися на main та запустити git merge beta -> push-notifications
- Видалити гілку push-notifications, і вона буде автоматично зафіксована в main
- Перемкнутися на beta та запустити git merge push-notifications
git add -A
- Усі нові та оновлені файли staged
- Файли розташовані в алфавітному порядку.
- Усі нові файли staged
- Лише оновлені файли staged
git remote -v
- Список віддалених сховищ та їх URL-адреси
- Поточна версію git, яку ви використовуєте
- Вбудований редактор для редагування віддалених сховищ
- Останні 5 версій git, які ви встановили
git checkout feature-user-location
git cherry-pick kj2342134sdf090093f0sdgasdf99sdfo992mmmf9921231
- коміт позначається тегом для випуску в гілці feature-user-location
- Коміт копіюється з оригінальної гілки до гілки feature-user-location
- Коміт обирається новим HEAD історії комітів
- Коміт копіюється з гілки feature-user-location до master
- Гілка перемикається на гілку feature-user-location, і вказаний коміт застосовується до гілки.
Пояснення:
'git checkout feature-user-location' перемикає на гілку 'feature-user-location'. 'git cherry-pick kj2342134sdf090093f0sdgasdf99sdfo992mmmf9921231' застосовує зміни з указаного коміту ('kj2342134sdf090093f0sdgasdf99sdfo992mmmf9921231') до поточної гілки (feature-user-location). Це фактично копіює коміт з його вихідної гілки до гілки feature-user-location. Таким чином, ця послідовність команд є вибором певного коміту для гілки feature-user-location.
git reset --soft HEAD^
- Видаляє всі попередні коміти та скидає історію сховища до початкового стану.
- Скидає робочу гілку до першого коміту.
- Зберігає HEAD у поточному коміті, але очищає всі попередні коміти.
- Встановлює HEAD до попереднього коміту та залишає зміни від скасованого коміту в stage/index.
Q9. Ви знайшли помилку у своєму проекті, але не можете знайти її в історії комітів. Як би ви діагностували цю проблему?
- Повернутися вручну за допомогою історії комітів.
- Скористатися git search -diff, щоб порівняти всі коміти в історії вашого сховища.
- Запустити git rebase, щоб знайти помилковий коміт.
- Скористатися git bisect для порівняння помилкового коміту з раннім комітом, що працює належним чином.
git rebase -i HEAD~10
- Для запуску порівняльного пошуку останніх 10 комітів на наявність відмінностей
- Для перераховування останніх 10 комітів і зміни їх за допомогою команди squash або fixup
- Для видалення останніх 10 комітів і скидання HEAD
- Для локального кешування останніх 10 комітів
- Непотрібно, можна скористатися ним в локальному сховищі
- Для виконання скріпта, коли віддалений пристрій отримує push, який запускається до оновлення будь-яких посилань
- Для запуску скріпта після оновлення віддаленого репозиторію
- Для налагодження всіх тегів комітів та версій
-
--all
-
--master
-
--global
-
--update
- Кешування
- Неможливо. git merge --squash — єдина команда git для цієї операції.
- Перебазування
- Рефлогінг
- Нова копія перезапише головний репозиторій
- Копію репозиторію буде створено на вашій локальній машині
- Нічого, клонування не підтримується функцією git
- Копія репозиторію буде створена на хостингу
- Знайти коміт у віддаленому сховищі, оскільки це єдине місце, де зберігається така інформація.
- Скористатися командою
diff-tree
з хешем коміту. - Запустити
git commit --info
з хешем коміту. - Отримати доступ до схованих даних комітів за допомогою
git stash
.
#.swift
build/
*.txt
*.metadata
- Всі файли з .swift, .txt, або metadata розширеннями, а також вся директорія build
- Тільки директорія build
- Всі файли в директорії build, також файли з розширеннями .txt або .metadata
- Тільки файли з розширеннями .swift та .txt.
Рядок, що починається з #
, є коментарем. Тому # .swift
нічого не робить. Дивіться man gitignore
.
git commit -a -m "Refactor code base"
- Нічого, ви не можете використовувати кілька параметрів в одній команді
- Додає всі нові файли до робочої області
- [] Фіксує всі нові файли з повідомленням
- Додає всі змінені файли до робочої області, а потім фіксує їх із повідомленням
Q18. Після перевірки git status ви отримаєте наступне, це показує що файл beta-notes.js присутній у коміті, але він також є unstaged. Як може статися така ситуація?
Change to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: beta-notes.js
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout --<file>..." to discard changes in working directory)
modified: beta-notes.js
- Було дві копії beta-notes.js, але одну було видалено
- beta-notes.js було створено, а потім змінено, створюючи дві різні версії файлу
- Було створено дві копії beta-notes.js, але лише одна відстежується
- Є дві відстежувані копії beta-notes.js, але одну було видалено з коміту
- У збережених файлах
- У документах git
- У Staging зоні
- [] У git кеш
- ⠀
git pull --all
git reset --hard origin/master
- ⠀
git pull -u origin master
git reset --hard master
- ⠀
git pull origin master
git reset --hard origin/myCurrentBranch
- ⠀
git fetch --all
git reset --hard origin/master
Примітка: - Команда pull
— це fetch
, за якою слідує merge
або rebase
(у цьому випадку merge
). Ми не хочемо мержити. Злиття було б дією для нашого репозиторію. Ми просто хочемо перезаписати наші локальні файли.
Q21. Ви виявили, що ваш проект має тег і гілку з однаковою назвою push-notifications, що викликає плутанину під час спроби роздрукувати дане посилання. Як вказати, яку гілку ви бажаєте переглянути?
- Скористатися git show refs/push-notifications
- Скористатися git show push-notifications
- Скористатися git show heads/refs/push-notifications
- Скористатися git show refs/heads/push-notifications
Q22. Перед виконанням rebase керівнику вашої команди потрібен перелік усіх комітів, які буде переміщено. За допомогою якої команди можна отримати доступ до цієї інформації?
- git rebase -log
- git rebase -i
- git rebase -verbose
- git rebase -all
git bisect start
git bisect bad 5d41402abc4b2a76b9719d911017c592
git bisect good 69faab6268350295550de7d587bc323d
- Злиття доброго коміту, який виявляється за допомогою відомого поганого та відомого доброго комітів
- Позначається коміт для видалення, використовуючи відомий поганий і відомий добрий коміти, щоб визначити, який коміт містить помилку
- Визначає поганий коміт і скидає HEAD, використовуючи відомий поганий і відомий добрий коміт
- Виконує бінарний пошук, використовуючи відомий поганий і відомий добрий коміти, щоб визначити, який коміт привніс помилку
Q24. У ситуації, коли у вас є кілька комітів для одного завдання, який найефективніший спосіб реструктуризувати вашу історію комітів?
- Перенести за допомогою сherry pick пов’язані коміти до іншої гілки.
- Видалити передані коміти та повторно передати з новим повідомленням.
- Стиснути пов’язані коміти разом у єдиний узгоджений коміт.
- Сховати пов’язані коміти під новим хешем.
Примітка. Яке твердження вірне щодо команди git push
?
- За замовчуванням push не надсилає теги до віддаленого рипозиторію.
- Коміти можна позначати тегами лише тоді, коли вони створені.
- Теги надсилаються до віддаленого сховища разом із відповідними комітами.
- Лише анотовані теги автоматично надсилаються до віддаленого сховища за допомогою коміту.
Q26. Яку скорочену команду ви можете використовувати в майбутньому після першого надсилання комітів до віддаленого сховища за допомогою наведеної нижче команди?
git push -u origin master
- git push master
- git push origin
- Як і раніше, git push -u origin master
- git push
- Запустите
git hotfix
з назвою ярлика. - Призначите ярлик або команду за допомогою файлу параметрів git.
- Використаєте команду
git custom-key
. - Створите псевдонім за допомогою команди
git config
.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: beta-notes.js
- beta-notes.js не відстежується та був змінений.
- beta-notes.js є відстежуваним файлом, який було змінено, але не додано до поточного коміту.
- beta-notes.js не відстежується, але його додано до поточного коміту.
- beta-notes.js відстежується, а змінений файл додано до поточного коміту.
- --fix
- --quickfix
- --modify
- --amend
- Масив даних
- Журнал даних
- Знімок даних
- Словник даних
git rm --cached testfile.js
- testfile.js буде видалено з проміжної області, а його зміни більше не відстежуватимуться.
- testfile.js буде видалено з проміжної області, але його зміни все одно відстежуватимуться.
- Копія testfile.js буде кешована на вашому робочому столі.
- Поточна копія testfile.js буде збережена в робочій області.
Q32. Після того, як ви успішно об’єднали дві гілки та внесли зміни, що буде наступним кроком у підтримці вашої структури git у порядку?
- Скористатися git reset --soft HEAD, щоб відкотити один коміт.
- Запустіти git branch -d
<назва гілки>
, щоб видалити об’єднану гілку. - Скористатися git clear-all, щоб очистити будь-які завислі файли.
- Запустіти git rebase, щоб перемістити поточний коміт у вихідне розташування.
Q33. Під час редагування файлу вам несподівано призначено термінове виправлення помилки в іншій гілці. Як ви можете тимчасово зберегти вашу локальну роботу без зобов’язань?
- Це неможливо, оскільки ви не можете зберегти локально без коміту.
- Запустити git hold, щоб зберегти локальну копію того, що ви робите, та повернутися до нього пізніше.
- Зберегти свою роботу за допомогою git local-cache.
- Скористатися git stash, щоб зберегти вашу роботу, а потім повернутися пізніше та повторно застосувати прихований коміт.
- git add
- git start
- git new
- git init
Q35. Під час роботи над гілкою feature ви намагаєтеся скористатися «git rerere» для вирішення повторюваного конфлікту merge, але нічого не відбувається. Що може бути причиною цієї проблеми?
- Параметр "-all" не додано до команди.
- "rerere.enabled" не ввімкнено у конфігураційному файлі.
- Хеш коміту відсутній.
- Шлях до файлу не вказано.
- core.page
- page
- pager
- core.pager
- Набір файлів, що представляють стан проекту на певний момент часу.
- Посилання на батьківські об’єкти коміту.
- Ім’я SHA1, рядок із 40 символів, який унікально ідентифікує об’єкт коміту.
- Посилання на батьківські об’єкти коміту та набір файлів, що представляють стан проекту на певний момент часу, а також ім’я SHA1, рядок із 40 символів, який унікально ідентифікує об’єкт коміту.
- %ce
- %cr
- %cd
- %cn
- 3
- 5
- 2
- 4
У Git є два основних способи інтегрувати зміни з однієї гілки в іншу: merge та rebase. Довідка
- git
- admin
- root
- Ніщо з цього
note: це питання недостатньо конкретне, щоб дати остаточну відповідь, оскільки воно залежить від конкретного випадку використання та конфігурації налаштування SSH.
- git tag 'v1.4.2'
- git tag -l 'v1.4.2.*'
- git tag-list 'v1.4.2*'
- git tag 'v1.4.2*'
- lieutenants
- benevolent dictator
- Залежить від типу проекту
- Залежить від даних
- add
- addfile
- begin
- track
- Все
- SSH
- Git
- HTTP
- Control
- Shift
- Tab
- Alt
- Розподілена система керування версіями
- Система відстеження проблем
- Інтегроване середовище розробки
- Служба розміщення репозиторіїв
- Файл
- Ніщо з цього
- Знімок
- Папка
- %am
- %ad
- %ae
- %an
Q49. Яка з пізніших версій Git пропонувала повернути файл до того вигляду, який був під час останнього коміту?
- 1.7
- 1.6
- 2.0
- 1.8
- LIFO
- recursive
- FIFO
- octopus
- значення SHA-1
- Ніщо з цього
- Назва гілки
- Назва проекту
- C
- C++
- C#
- Java
- ssh
- pub
- key
- pk
- Чисті репо зберігають свою історію git у підпапці .git.
- Чисті репозиторії не мають розширення .git.
- Чисті репозиторії не постачаються з робочими або вилученими вихідними файлами.
- Чисті репозиторії слід використовувати для локальних, а не віддалених репозиторіїв.
- будь-яка кількість комітів
- лише один локальний коміт на репозиторій
- лише три коміти на гілку
- лише один коміт на HEAD
- важкий і стислий
- легкий і незмінний
- важкий і коментований
- легкий і анотований
Q57. Після внесення серії змін до індексу, якою командою можна скористатися, щоб переглянути їх перед фіксацією?
- git diff --cached
- git diff
- git diff --HEAD
- git status -v -v
- видаляє останній запис тайника
- видаляє тайник
- перераховує все, що є в тайнику
- викидає найстаріший запис
-
git -b checkout <nameOfBranch>
-
git branch
-
git checkout <nameOfBranch>
-
git checkout -b <nameOfBranch>
Q60. Після помилкового розміщення файлу з назвою myFile до індексу, як би ви вилучили його з індексу, так щоб виключити одночасно і з вашого наступного коміту?
- Скористатися git reset HEAD^.
- Скористатися git reset myFile.txt.
- Скористатися git -rm myFile.txt.
- Скористатися git reset.
git checkout -b beta-test
- beta-test гілку буде вилучено з поточного коміту.
- Гілка beta-test буде перевірена та видалена.
- Буде створено та переключено на нову гілку під назвою beta-test.
- Гілка beta-test буде об’єднана з master гілкою.
- шляхом створення вказівника на останній знімок/коміт для гілки.
- шляхом створення масиву даних гілок у тому самому репозиторії.
- шляхом створення словника даних змін коду.
- створивши журнал налагодження, який зберігає зміни репозиторію.
Q63. Ви хочете виконати git reset, але не можете згадати всі доступні параметри. Яку команду ви б використали, щоб побачити їх опис?
- git help reset
- git -h reset
- git options reset
- git reset help
- версія репозиторію, яка відображає зміни, внесені в master гілку локального репозиторію для спільної роботи з відкритим кодом
- провідний репозиторій, обраний арбітром Git, знайдений в локальних репозиторіях членів команди, що співпрацює
- версія репозиторію лише для читання, що зберігається на сервері резервного копіювання, на випадок, якщо локальні репозиторії будуть втрачені або пошкоджені
- версія репозиторію, розміщена в Інтернеті або мережі, яка надсилається або витягується співавторами
Q65. Після зміни деяких існуючих файлів у репозиторії ви вирішуєте скасувати зміни. Якою командою можна скористатися?
- git restore
- git undo
- git clean
- git checkout .
Q66. Після початку об’єднання гілки feature з master гілкою ви стикаєтеся з конфліктом merge та вирішуєте, що не хочете виконувати merge. Як можна зупинити merge та відновити стан до merge?
- Скористатися git restore -p.
- Скористатися git merge -u.
- Скористатися git merge --abort.
- Скористатися git merge --undo.
-
git tag v3.8.1
-
git tag --light "v3.8.1"
-
git tag v3.8.1 —-annotate -m "<tagMessage>"
-
git tag -l v3.8.1
- Rebase впливає лише на ваш репозиторій і створює різницю в master гілці.
- Rebase створює тимчасову копію master гілки у віддаленому репо.
- Rebase переміщує HEAD віддаленої master гілки на один коміт вперед.
- Rebase видаляє всю історію комітів для нової feature гілки.
Q69. Який робочий процес Git використовують команди, які співпрацюють над однією гілкою та уникають створення довготривалих гілок розробки?
- Git flow
- Mainline flow
- Trunk-Based Development
- GitHub flow
Q70. Який параметр у команді git log дозволяє обмежити виведення комітами, зробленими після певної дати?
-
--since
-
--sinceWhen
-
-<n>
-
--afterDate
-
git cache --obsolete <time>
-
git branch --rebase <time>
-
git delete --inert <time>
-
git prune --expire <time>
- У віддаленій master гілці могли бути перезаписані існуючі зміни.
- URL-адресу джерела буде скинуто до значення за замовчуванням.
- Поточний HEAD буде видалено та не можливо буде відновити.
- Нічого, це звичайна практика примусового push після rebase.
- Git працює лише в Linux, тоді як SVN працює в усіх операційних системах.
- SVN працює тільки в Linux, тоді як Git працює в усіх операційних системах.
- SVN — централізована система, а Git — розподілена система.
- Git — централізована система, а SVN — розподілена система.
git tag -a v1.4 -m "ABCD v1.5"
- багатослівний
- анотований
- легкий
- відкладений
- М’яке скидання змінює лише комміт, на який вказує HEAD, тоді як жорстке скидання скидає індекс і робоче дерево відповідно до вказаного коміту, відкидаючи будь-які зміни.
- М'яке скидання кешує старий покажчик HEAD, тоді як жорстке скидання видаляє його повністю.
- Жорстке скидання змінює лише те, куди вказує HEAD, тоді як м’яке скидання змінює HEAD та індекс.
- Жорстке скидання кешує старий покажчик HEAD, тоді як м’яке скидання видаляє його повністю.
Який із наведених варіантів правильний?
-
1. Develop 2. Release 3. Hotfix 4. Feature 5. Master
-
1. Master 2. Release 3. Hotfix 4. Feature 5. Develop
-
1. Develop 2. Master 3. Hotfix 4. Feature 5. Develop
-
1. Master 2. Hotfix 3. Develop 4. Feature 5. Release
- скрипти оболонки та прапорці
- в’язка ключів та інформація про обліковий запис
- параметри локального та глобального репозиторіїв
- сценарії попередньої компіляції та налаштування
- тип архітектури, що використовується для керування великими базами даних
- система, яка показує, відстежує та контролює зміни в наборі файлів з часом
- шаблон програмного проектування, який використовується для керування кодом між кількома командами інженерів
- тип програмного забезпечення, яке пов’язує проект із сховищем GitHub
-
git stash
видаляє коміт з історії репо, тоді якgit stash pop
зберігає зміни в кількох гілках. -
git stash
зберігає зміни в кількох гілках, тоді якgit stash pop
видаляє коміт з історії репо. -
git stash
видаляє останній комміт, тоді якgit stash pop
зберігає поточні зміни. -
git stash
створює запис у схованці, тоді якgit stash pop
розміщує збережений стан зі списку схованок у робочий каталог.
Q80. Яку команду можна використати для переліку гілок, які були об’єднані в поточну перевірену гілку?
- git master --status
- git branch --status
- git branch --merged
- git status --merged
Q81. Як би ви налаштували Git на переривання коміту, якщо сценарій димового тесту не вдається виконати?
- Створити post-commit shell script, який ініціює дію.
- Створити post-commit хук для запуску скрипта.
- Створити pre-commit хук для запуску скрипта.
- Створити pre-commit shell script, який ініціює дію.
- стан залежить від змін середовища
- безперервна інтеграція
- збільшення покриття коду
- виконання правил комітів
- покажчики shell script та облікові дані keychain
- оновлення підказок щодо гілок та інших посилань у локальному репозиторії
- примітки до випуску та значення сценарію підключення
- тег і інформація про версії
Q84. Ви щойно завершили rebase master гілки, і вам потрібно вручну оновити віддалену master, навіть якщо існує конфлікт merge. Як ви можете цього досягти?
-
git push --overwrite
-
git push --update
-
git push --assert
-
git push --force-with-lease
-
git fetch
створює нову гілку з master гілки, тоді якgit pull
створює нову гілку з master гілки локального репозиторію. -
git pull
завантажує нові дані з віддаленого репозиторію без інтеграції їх у локальні файли, тоді якgit fetch
оновлює HEAD поточної гілки останніми змінами з віддаленого сервера. -
git fetch
оновлює гілки віддаленого відстеження змінами з віддаленого репозиторію, тоді якgit pull
оновлює гілки віддаленого відстеження змінами з віддаленого репозиторію та об’єднує їх у відповідні локальні гілки. -
git fetch
завантажує та об’єднує дані з локального репозиторію, тоді якgit pull
інформує ваших колег про те, що ви збираєтесь внести зміни до master гілки.
Q86. Яка команда відображає різницю між індексом робочого дерева, а також файлами, які не відстежуються Git?
-
git current
-
git status
-
git local
-
git context
- Скористатися
git branch <stash hash>
. - Додайти сховані коміти до поточного коміту, а потім створити нову гілку.
- Скористатися
git checkout -b
. - Запустити
git stash branch <branch name>
.
- -D видаляє локальну гілку, тоді як -d видаляє гілку незалежно від статусу push і merge.
- -d видаляє поточний HEAD коміту, тоді як -D видаляє всю гілку.
- -d видаляє локальну гілку, тоді як -D видаляє локальну гілку незалежно від статусу push і merge.
- -D видаляє поточну HEAD коміту, тоді як -d видаляє всю гілку.
Q89. Ви зберегли три набори змін, але не пам’ятаєте вміст першого запису. Яку команду ви використали б, щоб переглянути подробиці змін у першому з трьох записів схованки?
- git stash show -p stash@{2}
- git stash list
- git stash show -p stash@{1}
- git stash show -p
- Скористатися
git --delete <branch_name>
. - Скористатися
git push <remote_name> --d <branch_name>
. - Скористатися
git push <remote_name> --D
. - Скористатися
git push <remote_name> --delete <branch_name>
.
- delete
- expire
- show
- update
- Це призводить до того, що відстежувані файли в батьківському каталозі включаються до staged файлів.
- Це дозволяє розробникам інтерактивно вибирати, які зміни у відстежуваних файлах буде встановлено, і виводить відмінності для перегляду.
- Автоматично надсилає зміни до відповідної гілки віддаленого репозиторію.
- Це дозволяє розробникам інтерактивно вибирати, які файли закріплено, і виводить відмінності для перегляду.
Q93. Після перевірки певного коміту ви отримуєте попереджувальне повідомлення про те, що ви перебуваєте в стані «detached HEAD». Про що вас попереджає Git?
- Ви не працюєте над останнім комітом гілки.
- Товариш по команді позначив код із проблемою.
- Коміт не має батьківського елемента.
- Гілка не була надіслана до віддаленого репозиторію.
- Її неможливо відновити.
- Знайти хеш гілки за допомогою команди
log
, потім виконатиgit checkout -b <назва гілки> <хеш>
. - Знайти хеш гілки за допомогою команди
reflog
, потім виконатиgit checkout -b <назва гілки> <хеш>
. - Виконати
git checkout -b <назва гілки>
.
Q95. Як відобразити гістограму, що показує вставки, видалення та модифікації для кожного файлу для певного коміту разом із загальною інформацією про коміт?
- Скористатися
git stat
. - Скористатися
git debug --prettyprint
. - Надіслати запит до віддаленого репозиторію за допомогою хешу коміту.
- Скористатися
git show <commit> --stat
.
- Менеджери репозиторіїв є власними версіями Git, які не містять розширених функцій.
- Менеджери репозиторіїв надають розширений інструмент командного рядка, який використовується для керування кількома локальними репозиторіями.
- Менеджери репозиторіїв надають онлайн-сервіс для розміщення репозиторіїв Git, які включають такі функції співпраці, як запити на отримання, відстеження проблем і експертні оцінки.
- Менеджери репозиторіїв розподіляють репозиторії між кількома місцями на робочій станції користувача, забезпечуючи надлишкове сховище, що дозволяю робити швидке резервне копіювання та відновлення.
-
git head --verify
-
git log --head
-
git hash --head
-
git show-ref --head
- Тривалі гілки зберігають нестабільний код, доки він не буде рецензований для інтеграції в гілку feature.
- Тривалі гілки відповідають гнучким спринтам і використовуються для зберігання пов’язаних із feature розробок під час спринту.
- Довгострокові гілки містять код, пов’язаний з feature розробкою, який об’єднується в короткострокові гілки, такі як master.
- Тривалі гілки відповідають різним стадіям розробки та завжди відкриті для залучення тематичних/feature гілок.
Примітка: master не є короткочасною гілкою, як зазначено у відповіді «C». Відповідь «D» правильна. Довідка
Q99. Яка команда приймає зміни з master гілки у джерелі віддаленого репозиторію, а потім об’єднує з локальною вилученою гілкою?
-
git commit -u origin
-
git checkout origin
-
git pull origin master
-
git push origin master
Q100. Під час надсилання змін до віддаленого репозиторію ви отримуєте таке повідомлення. Як вирішити цю проблему?
error: failed to push some refs to 'https://github.com/myrepo/simple.git'
hint: Updates were rejected because the remote contains work that you do not hint: not have locally.
- Скористатися опцією --atomic із командою push.
- Виконати pull, потім розв’язати будь-які конфлікти merge та виконати push знову.
- Виконати fetch, потім виконати push.
- Скористатися параметром --force з командою push.
- Він додає доповнення до виводу, яке показує відмінності, введені в кожному коміті.
- Він додає доповнення до виводу, яке показує короткий перелік змінених файлів.
- Він додає доповнення до виводу та відображає гістограму, яка показує кількість рядків, змінених у кожному коміті.
- Він додає повне повідомлення коміту та примітки, пов’язані з кожним комітом.
- область, яка зберігає коміти до того, як їх буде відправлено у віддалений репозиторій
- область, що містить схованки, які можна застосувати до робочих файлів
- область, де зберігаються зміни з гілки у віддаленому репозиторії перед тим, як їх застосувати до локальної гілки
- область, яка зберігає інформацію про зміни, які будуть включені до наступного коміту
Q103. Яку команду ви використали б для внесення змін до індексу виключно для файлів властивостей у поточному каталозі?
-
git add *.properties
-
git add %.properties
-
git add .properties
-
git add properties
- файли в локальному репозиторії, які не були об’єднані в master гілку
- проміжні файли, про які Git не знає, оскільки вони не були закомічені
- файли у робочому каталозі, про які Git не знає, тому що вони не були підготовлені(staged) чи закомічені
- файли у віддаленому репозиторії, про які Git не знає, оскільки вони не позначені тегами
Q105. Який тип хуків Git можна використати для підтвердження того, що повідомлення коміту містить номер квитка?
- pre-commit
- commit-msg
- applypatch-msg
- prepare-commit-msg
- git stash pop переміщує найвищий комміт до поточної гілки, тоді як git stash apply кешує останній комміт у поточній гілці.
- git stash pop застосовує найвищий запис у схованці до робочих файлів і видаляє його зі схованки, а git stash apply застосовує найвищий запис у схованці до робочих файлів, але залишає його в схованці.
- git stash pop об’єднує найвищий комміт із поточною гілкою, тоді як git stash apply об’єднує з останній комміт у поточній гілці.
- git stash pop застосовує найвищий запис у схованці до робочих файлів, але залишає його в схованці, тоді як git stash apply застосовує найвищий запис у схованці до робочих файлів і видаляє його зі схованки.
Q107. Після внесення деяких значних змін у ваш код ви трохи хвилюєтеся перед комітом. Яку команду ви б використали для перегляду коміту перед його створенням?
- git commit --verify
- git notes show
- git commit preview
- git commit --dry-run
- вказівник на останній змінений файл у stage/index
- вказівник на master гілку
- вказівник на останній комміт у поточній гілці
- вказівник на те, де в пам’яті зберігається репозиторій
Q109. Після внесення змін до кількох файлів ви розумієте, що зміни у файлі config.properties є неправильними, і їх потрібно видалити з робочої області та каталогу. Якою командою можна видалити поетапні зміни у файлі?
- git reset HEAD^ -- config.properties
- git rm config.properties
- git rf config.properties
- git checkout HEAD -- config.properties
Q110. Після останнього релізу з трасуванням стека створюється помилка, яка вказує на те, що проблема пов’язана з нещодавно доданою властивістю конфігурації під назвою MaxConnections. Яка команда може знайти всі коміти, які додають або видаляють рядок MaxConnections?
- git grep -a "MaxConnections"
- git log --search-string "MaxConnections"
- git log -S "MaxConnections"
- git commit --with "MaxConnections"
Q111. Ваша компанія перемістила свій віддалений репозиторій на GitHub за цією адресою: https://github.com/yourcompany/core-api.git. Яка команда оновлює віддалений репозиторій з іменем origin, щоб вказувати на новий віддаленний репозиторій в цьому місці?
- git remote create-update origin https://github.com/yourcompany/core-api.git
- git remote update origin https://github.com/yourcompany/core-api.git
- git remote set-url origin https://github.com/yourcompany/core-api.git
- git remote add https://github.com/yourcompany/core-api.git
- коли комміт з однієї гілки потрібно скопіювати в іншу гілку
- коли HEAD потрібно скинути до певного коміту
- коли певний комміт потрібно витягнути з віддаленого репозиторію
- коли потрібно викликати сценарій підключення
- видалена або заархівована копія репозиторію
- бета-версія гілки репозиторію
- майбутня гілка репозиторію
- окрема копія репозиторію
- Неможливо виключити файли з репозиторію.
- Позначити файли тегом виключено.
- Додати шаблон, що відповідає файлам, до файлу .gitignore.
- Додати файли до пропущеної гілки
-
git checkout <url>
-
git pull <url>
-
git clone <url>
-
git replicate <url>
- testfile.js буде повернуто до порожнього стану.
- testfile.js буде скинуто до свого першого збереженого стану.
- testfile.js буде повернено до стану своєї останньої збереженої копії.
- testfile.js буде видалено з області stage/index, якщо він присутній.
Q117. Яка ситуація може виникнути під час спроби об’єднати гілки, що містять зміни в одному фрагменті коду?
- lost code
- automatic override
- collisions
- merge conflict
- Topic гілки зберігають нестабільний код, доки його не перевірять для інтеграції в іншу feature гілку.
- Topic гілки відповідають різним стадіям розвитку і завжди відкриті для залучення довготривалих гілок.
- Topic гілки використовуються в методології розробки каскаду для відстеження стану коду на різних етапах каскаду.
- Topic гілки – це короткочасні гілки, які використовуються для зберігання роботи, пов’язаної з певною функцією.
- Надати докладні повідомлення про коміти, які описують зміни, внесені комітом.
- Робити великі коміти, які вводять чисельні функції.
- Підтримувати синхронізацію гілок локального репозиторію з зв'язаними гілками у віддаленому репозиторії шляхом частих комітів, push та pull.
- Уникати частої взаємодії з віддаленим репозиторієм, щоб зменшити ймовірність конфліктів.
-
git rm -all
-
git rm --cached
-
git clean -d -f
-
git checkout
Примітка. У Git, коли кілька коротких опцій використовуються разом, ви можете об’єднати їх в одну опцію, пропускаючи пробіл між ними. Отже, git clean -d -f
можна поєднати як git clean -df
.
Q121. Після здійснення коміту ви помітили, що забули внести зміни до файлу doge.txt. Яку команду або команди ви б використали, щоб додати зміни до коміту?
- ⠀
git add doge.txt
git commit --amend --no-edit
- ⠀
git commit --amend --no-edit
- ⠀
git add doge.txt
git commit --patch --no-edit
- ⠀
git commit --patch --no-edit
Q122. Яка команда видалить файл під назвою wrongfile із поточної гілки сховища, індексу та робочих файлів?
- ⠀
git rm wrongfile
git commit -m "Removed file"
- ⠀
git forget -rf wrongfile
git commit -m "Removed file"
- ⠀
git untrack -rf wrongfile
git commit -m "Removed file"
- ⠀
git rm --cached wrongfile
git commit -m "Removed file"
- Надіслати email власнику проекту.
- Я не поспішаю повідомляти про помилки програмного забезпечення, тому що немає прозорості, і вони все одно ніколи не виправляються.
- Знайти помилку в існуючих issues проекту та створити нову issue, якщо про неї ще не повідомляли.
- Скористатися git search -diff, щоб порівняти всі коміти в історії вашого репозиторію.
Пояснення: issues проекту бачать усі, хто має доступ до проекту, тому ви можете виявити, що вирішення вже заплановане або доступне. В іншому випадку ви можете створити та відстежити issue самостійно.
Q124. Припустімо, ви створили bug fix у новій гілці та хочете, щоб воно стало частиною наступної робочої збірки, створеної з main гілки. Що робити далі?
- Скопіювати зміни вашої гілки та закомітити їх безпосередньо в main гілці.
- Створити pull request to merge, щоб об’єднати нову гілку з основною гілкою.
- Якщо добре подумати, можливо, я не буду ділитися цим виправленням. Я просто поміщу це у свою особисту версію вихідного коду.
- Скористатися git bisect, щоб порівняти коміт з помилками та ранній коміт, який працює належним чином.
Пояснення: Pull requests є правильним способом повідомити, що коміти готові до перегляду та остаточного включення в main гілку.
- контроль версій
- Платформа хостингу для репозиторіїв Git
- для збереження зображень
- для соціальних мереж
- Add та commit.
- branch та checkout.
- fetch та merge.
- Ніщо з цього.
- git email.user
- git config user.email
- git config email
- Все вищеперераховане.
Q128. _ перемотає ваш проект до певного моменту часу, втрачаючи всі коміти, які з’явилися після нього. _ збереже зміни в цих перемотаних комітах як локальні модифікації
-
git reset HEAD
;git reset HEAD^
-
git reset --hard
;git reset --soft
-
git reset --soft
;git reset --hard
-
git rewind
;git update
Q129. Поясніть концепцію «Git blame» і коли вона використовується в робочому процесі керування версіями.
- [] Git blame — це команда для пошуку та розкриття ідентичності учасників у репозиторії Git.
- Використовується для звинувачення інших у проблемах з кодом у спільному проекті.
- Git blame — це функція для відстеження розташування помилок у коді.
- Git blame — це інструмент для відображення того, хто останнім змінював кожен рядок файлу, допомагаючи відстежувати зміни та розуміти історію коду та авторство.
- Конструктор переміщення створює глибокі копії об’єктів, покращуючи ефективність пам’яті.
- Він генерується, коли ви явно визначаєте конструктор копіювання.
- Конструктор переміщення використовується для копіювання об'єктів між різними типами даних.
- Конструктор переміщення дозволяє ефективно передавати ресурси від одного об’єкта до іншого, зменшуючи непотрібне копіювання.
Untracked files:
(use "git add <file>..." to include in what will be committed)
broccoli
-
git remove .
-
git remove broccoli
-
git clean
-
git clean -f
- [x], щоб дозволити вам створювати файли .zip, якими ви можете легко ділитися
- [ ], щоб почати безперервний процес інтеграції
- [x], щоб упакувати ваше програмне забезпечення, щоб воно стало доступним через торговий майданчик Github
- для створення робочих процесів та автоматизації процесу генерації програмного забезпечення
Q133. Ви переглядаєте сторінку репозиторію та клацаєте назву папки, щоб відкрити її. Ви ввімкнули пошук коду, тому ви потрапляєте у вікно перегляду коду. Який найшвидший спосіб знайти файл на шляху у вашому репо?
- Натиснути клавішу slash(/), а потім клавішу T.
- Перейти до розширеного пошуку.
- У меню пошуку вибрати Шлях.
- Натиснути клавішу T.
- Натиснути Save у полі пошуку.
- Натиснути Save в меню розширеного пошуку.
- Натиснути Save на сторінці результатів пошуку.
- Додати сторінку результатів пошуку в закладки.
- bug
- documentation
- wontfix
- repo
- Натиснути клавішу похилої риски (/) на будь-якій сторінці сайту.
- Натиснути вкладку Пошук у версії Github
- Натиснути посилання розширеного пошуку.
- Натиснути поле пошуку та ввести пошуковий запит.
- отримає сповіщення з проханням переглянути issue
- відповідає за вирішення issue
- отримає інформацію про деталі issue
- контролює команду, яка вирішує issue
- Створює живу демонстрацію поточного репозиторію для навчання.
- Дозволяє створювати типову структуру та файли на основі поточного репозиторію.
- Дозволяє архівувати та зберігати налаштування проекту.
- Імпортує налаштування іншого проекту до поточного проекту.
- Щоб дозволити створювати файли .zip, якими можна легко ділитися
- Ініціювати постійний процес інтеграції
- Упакувати програмне забезпечення, щоб воно стало доступним через Github Marketplace
- Для створення робочих процесів та автоматизації процесу генерації програмного забезпечення
- Додати інструкції в дужках.
- Скористатися короткими, але точними дескрипторами.
- Додати контекст у коментарях.
- Скористатися короткими назвами змінних.
- Скористатися описовими назвами функцій.
- Для пошуку відповідей у сховищі поточного проекту
- Щоб спілкуватися з іншими розробниками, які працюють у вашій компанії
- Для розмови з ШІ за допомогою Copilot
- Щоб отримати список можливих відповідей на запитання
Q142. Під час перегляду коду ви хочете розпочати issue, виділивши функцію, яка займає кілька рядків коду. Який найшвидший спосіб зробити це в режимі перегляду коду?
- Клацнути номер першого рядка з функцією, клацнути номер останнього рядка, щоб вибрати діапазон, а потім у гамбургер-меню вибрати Reference in new issues
- Скопіювати код і створити нову issue, а потім скористатися зворотнею галочкою навколо функції, щоб створити issue
- Вибрати функцію мишкою, потім клацнути правою кнопкою миші та вибрати reference in new issue
- Клацнути номер рядка з функцією та вибрати reference function in an issue
Q143. Ви переглядаєте файл у репозиторії та хочете зробити посилання на поточну версію файлу, навіть якщо його буде оновлено пізніше. Як цього досягти?
- Перейти на вкладку Код і натиснути Завантажити zip
- Клацнути правою кнопкою миші текст коду та обрати Permalink
- Клацнути Permalink у вікні перегляду коду
- Скопіювати URL-адресу з адресного рядка
Q144. Ви організовуєте проект desktop програми. Ви хочете використовувати огляд статусів своїх проектів і мати можливість перетягувати issues. Який вигляд ви б використали?
- Board
- Overview
- Roadmap
- Table
Q145. Ви перебуваєте в репо для певного проекту під час роботи над модулем програми. Ви хочете знайти деякі з документів, над якими ви працювали, які ви написали у розмітці. Щоб швидко знайти у своєму власному репозиторії всі файли з розширенням markdown, натисніть кнопку slash (/) на клавіатурі на сторінці репо та введіть ___.
- Path:.md
- Grep:.md
- Code:*.md
- Ext:*.md
- Позначити елемент своїм іменем користувача.
- Обрати ім’я користувача в полі Assignees.
- Перемістити елемент у відповідний стовпець у Boards перегляді.
- Додати їх маркер у коментарях.
- Це допомагає Copilot додати більше змінних до функції.
- Це навчає алгоритм, щоб наступного разу клієнт GitHub відповідав на запитання.
- Це допомагає Copilot мати кращий контекст для допомоги та створення коду.
- Назви функцій не передаються Copilot і ігноруються ШІ.
Q148. Ви працюєте над проектом, який використовує бібліотеку Python, і хочете знайти приклад використання функції в усіх публічних репозиторіях. Яку частину платформи GitHub ви б використали?
- Issues.
- Discussions
- Projects
- Search
Q149. Працюючи над проектом допізна, вам потрібно знайти issue, яке було вам назначено. Який запит ви вводите?
- Is:issue assignee:username
- Is:issue user:username
- Issue:issue user:username
- assignee:username is:rep
Q150. Ви працюєте над додатком ШІ та вам потрібно додати інформацію про цільову модель ШІ в таблиці проекту. Яка функція дозволяє це зробити?
- Custom fields
- Comments
- Pull requests
- Custom properties
- Таблиця візуалізованих даних
- Структура таблиці markdown
- Структура таблиці HTML
- Зміст
- Ввести «function», а потім додати детальну та виразну назву функції.
- Ввести «function», а потім натиснути Ctrl+/ (Windows) або Command +/ (Mac).
- Додати змінні в дужки.
- Скористатися узгодженним форматуванням для назв функцій.
- Це дозволяє вказати, який тип машини обрати.
- Це допомагає запускати робочі процеси.
- Запускає додатковий контейнер
- Це дозволяє виконувати команду shell під час процесу генерації образу
- Ввести свій запит у дужках
- Скористатися кваліфікатором exact:
- Взяти ряд слів у лапки
- Додати оператор AND в кінець запиту
- Це дає інструкції контейнеру Docker, які слід виконати перед завантаженням
- Це виконує скрипт під час запуску контейнера.
- Це служить першим файлом, який редактор відкриває під час завантаження контейнера.
- Це вказує на конкретну команду, яку потрібно виконати під час процесу створення образу Docker
Q156. Яке ключове слово в actionы GitHub ви використовуєте, щоб указати операційну систему для виконання завдань?
- Hardware
- Runs-on
- Machine
- Os
- Клацнути файл правою кнопкою миші та додати його до контексту
- Відкрити додаткові вкладки з деяким вашим кодом; вони будуть у контексті Copilot
- Створити коментар зі списком файлів, з яких Copilot має мати контекст
- Виділити файли, до яких потрібно додати контекст, щоб сформувати бічну панель файлів
- *3.2.4
- @3.2.4
- #3.2.4
- V3.2.4