10 вопросов по GIT (вопросы 501 - 510)⁠⁠

Дисклеймер 1. На пикабу все еще не завезли редактор кода, поэтому картинки.
Дисклеймер 2. Как правило, я даю вопросы и ответы в одном посте. В этой серии вопросов я вынужден разбить тему на два поста, ибо лимит.

Вопрос 501. В чем заключается ключевое различие между командами git fetch и git pull, и какая из них считается более "безопасной" для использования в командной работе?

• A. git pull загружает изменения, а git fetch сливает их с локальной веткой.

• B. git fetch загружает изменения из удаленного репозитория, но не применяет их к локальной рабочей ветке, в то время как git pull загружает изменения и немедленно пытается их слить (merge) с текущей веткой.

• C. git fetch и git pull являются синонимами и выполняют одно и то же действие — синхронизацию с удаленным репозиторием.

• D. git fetch используется для получения списка веток, а git pull — для отправки изменений на удаленный сервер.

Вопрос 502. Вы только что сделали коммит, но сразу поняли, что забыли добавить в него один важный файл. Какую последовательность команд следует использовать, чтобы добавить этот файл в самый последний коммит, не создавая при этом нового коммита в истории?

• A. Сначала добавить забытый файл командой git add , а затем выполнить git commit --amend --no-edit, чтобы обновить последний коммит.

• B. Выполнить git revert HEAD, чтобы отменить последний коммит, а затем создать новый, правильный коммит.

• C. Использовать git update для прямого добавления файла в уже существующий коммит.

• D. Создать новый коммит с этим файлом, а затем использовать git merge HEAD~1, чтобы объединить его с предыдущим.

Вопрос 503. Какую роль играет "staging area" (или "index") в рабочем процессе Git, и каково его основное предназначение?

• A. Это временное хранилище (аналогичное git stash) для незавершенных изменений, которые еще не готовы к коммиту.

• B. Это промежуточная область, куда разработчик помещает готовые изменения (git add), чтобы сформировать из них следующий коммит. Она позволяет включать в коммит только часть изменений из рабочего каталога.

• C. Это специальная ветка, в которой хранятся все конфликты слияния для их последующего разрешения.

• D. Это область, где Git хранит полную историю всех изменений в проекте, являясь синонимом локального репозитория.

Вопрос 504. В чем заключается принципиальное различие в результате применения команд git merge и git rebase для интеграции изменений из одной ветки в другую, и какой из подходов создает более линейную историю коммитов?

• A. git merge создает специальный "коммит слияния", который объединяет истории двух веток, сохраняя их параллельное развитие. git rebase переносит коммиты из одной ветки в начало другой, создавая линейную историю.

• B. git rebase создает коммит слияния, а git merge переносит коммиты одной ветки поверх другой, изменяя их хеши.

• C. git merge используется для слияния текстовых файлов, в то время как git rebase оптимизирован для работы с бинарными файлами.

• D. git rebase является более безопасной операцией, так как автоматически разрешает все конфликты, в отличие от git merge, который всегда требует ручного вмешательства.

Вопрос 505. Вы работаете над задачей в своей ветке, и у вас есть несколько измененных, но еще не готовых к коммиту файлов. Внезапно вас просят срочно исправить критический баг в ветке main. Какой из следующих подходов является наиболее правильным и стандартным для временного сохранения вашей текущей работы, переключения на другую ветку и последующего возвращения к своим изменениям?

• A. Использовать команду git stash, чтобы временно сохранить все отслеживаемые измененные файлы, переключиться на ветку main, а после исправления бага вернуться в свою ветку и применить изменения командой git stash pop.

• B. Создать временный коммит с сообщением "WIP" (Work In Progress), переключиться на main, а по возвращении отменить этот коммит командой git reset --soft HEAD~1, чтобы вернуть изменения в рабочий каталог.

• C. Использовать команду git checkout -f main для принудительного переключения на ветку main, что автоматически сохранит ваши изменения для последующего восстановления.

• D. Скопировать измененные файлы в другую папку на компьютере, отменить все локальные изменения командой git reset --hard, а после исправления бага скопировать файлы обратно.

Вопрос 506. Вы отправили важный коммит в общий удаленный репозиторий (git push), но позже обнаружили в нем ошибку. Какой командой следует "отменить" изменения этого коммита, сохранив при этом историю безопасной и понятной для всей команды?

• A. Использовать команду git revert <commit_hash>, которая создаст новый коммит, отменяющий изменения указанного коммита, и при этом не изменяет существующую историю.

• B. Использовать git reset --hard HEAD~1, чтобы удалить ошибочный коммит, а затем принудительно отправить изменения с помощью git push --force.

• C. Использовать git commit --amend, чтобы исправить ошибку и перезаписать последний коммит, после чего отправить его с помощью git push --force.

• D. Использовать команду git delete commit <commit_hash>, которая безопасно удаляет коммит из истории как локально, так и удаленно.

Вопрос 507. Для чего предназначена команда git cherry-pick и в каком сценарии ее использование будет наиболее оправданным?

• A. Она применяет один или несколько выбранных коммитов из одной ветки в другую. Это особенно полезно для переноса конкретных исправлений (hotfix) без необходимости слияния всей ветки.

• B. Она переносит все коммиты из текущей ветки поверх другой, создавая линейную и чистую историю коммитов.

• C. Она создает специальный "коммит слияния", который включает в себя изменения только из одного указанного коммита другой ветки.

• D. Она используется для сравнения содержимого одного конкретного коммита с файлами в текущем рабочем каталоге.

Вопрос 508. Вы случайно выполнили команду git reset --hard и потеряли несколько последних локальных коммитов, которые еще не были отправлены в удаленный репозиторий. Существует ли в Git механизм для восстановления этих "потерянных" коммитов, и если да, то какая команда для этого используется?

• A. Нет, команда git reset --hard необратима. Все потерянные коммиты удаляются навсегда без возможности восстановления.

• B. Да, можно использовать git reflog, чтобы найти хеши "потерянных" коммитов и восстановить их, создав новую ветку от нужного коммита.

• C. Да, можно использовать команду git restore --lost-commits, которая автоматически найдет и восстановит все удаленные коммиты.

• D. Восстановление возможно только путем клонирования репозитория заново с удаленного сервера, но локальные коммиты будут утеряны.

Вопрос 509. Что представляет собой команда git bisect, и какой основной алгоритм лежит в её основе для эффективного поиска коммита, который внес ошибку в код?

• A. Это инструмент, который автоматически выполняет бинарный поиск по истории коммитов, чтобы найти первый коммит, внесший ошибку. Разработчик помечает коммиты как «хорошие» (good) и «плохие» (bad), сужая диапазон поиска.

• B. Эта команда последовательно проверяет каждый коммит один за другим, начиная с последнего, и запускает автоматические тесты, пока не найдет сломанный коммит.

• C. Она анализирует указанный файл и показывает, какой коммит и какой автор последними изменяли каждую строку, помогая найти виновника ошибки в конкретном файле.

• D. Она разделяет (bisects) ветку на две новые ветки в указанном коммите для проведения A/B тестирования функциональности.

Вопрос 510. Как файл .gitignore влияет на файлы, которые уже отслеживаются системой контроля версий Git, и какая последовательность действий необходима, чтобы заставить Git перестать отслеживать такой файл, не удаляя его из локальной файловой системы?

• A. Добавления файла в .gitignore достаточно. Git автоматически перестанет отслеживать его при следующем коммите.

• B. .gitignore не влияет на уже отслеживаемые файлы. Чтобы перестать отслеживать файл, нужно сначала удалить его из индекса Git с помощью git rm --cached <file>, а затем закоммитить это изменение.

• C. Файл .gitignore предназначен только для игнорирования папок, а не отдельных файлов.

• D. Нужно использовать git reset <file>, чтобы убрать файл из staging area, после чего .gitignore начнет действовать.

Ответы с примерами и объяснением 10 вопросов по GIT (вопросы 501 - 510) Ответы
Подпишись, чтобы не пропустить

Удачи!