-
Основы Git
- Как работает `git cherry-pick`?
- Что делает `git rebase -i` и когда он используется?
- Объясните, что такое fast-forward merge.
- Что произойдет при конфликте слияния и как его решить?
- Что выведет следующая последовательность команд? ```bash git init echo "one" > a.txt git add a.txt git commit -m "first" git checkout -b feature echo "two" > a.txt git commit -am "second" git checkout main echo "three" > a.txt git commit -am "third" git merge feature ```
- В чём отличие `git reset`, `git checkout`, `git restore`?
- Что делает команда `git reflog`?
- Как восстановить удалённую ветку?
- Как работает `git bisect`?
- Что делает `git blame`, и когда он полезен?
- Что выведет следующая команда, если `file.txt` удалён и закоммичен, а потом выполнено `git checkout HEAD file.txt`? ```bash git rm file.txt git commit -m "remove file" git checkout HEAD file.txt ls ```
- Как отменить merge, если он уже завершён?
- Как работает механизм хука в Git?
- Как создать патч и применить его в другом репозитории?
- Чем отличается `origin/master` от `master`?
-
Работа с удалёнными репозиториями
- Как проверить, есть ли различия между локальной и удалённой веткой?
- Что произойдет, если сделать `git push --force`?
- В чём опасность использования `--force` и когда он оправдан?
- Как безопасно переписать историю публичной ветки?
- Что выведет следующая последовательность? ```bash git checkout -b new-feature echo "new" > file.txt git commit -am "new feature" git push origin new-feature git reset --hard HEAD~1 git push origin new-feature --force ```
- Как работает `git bundle` и когда используется?
- Что делает `git submodule`?
- Как клонировать репозиторий вместе с сабмодулями?
- Как синхронизировать сабмодули?
- Что делает команда `git fetch --prune`?
- Как получить изменения только одного файла с удалённого репозитория?
- Что происходит при выполнении `git push --mirror`?
- Как перенести весь репозиторий на другой сервер?
- В чём отличие `git archive` от `git clone`?
- Что означает сообщение “non-fast-forward” при попытке `push`?
-
Продвинутые возможности Git
- Как обойти хук при выполнении коммита?
- Что такое `git rebase -i` и как с его помощью можно объединить коммиты?
- Как работает стратегия слияния `ours`?
- Как отменить rebase, если произошла ошибка?
- Что выведет следующая команда при интерактивном rebase? ```bash git rebase -i HEAD~3 ``` (сценарий: pick → squash → reword)
- Как использовать `git worktree` и зачем он нужен?
- Как настроить `git rerere` и что он делает?
- Что делает `git notes` и как это использовать?
- Как использовать `git filter-branch` для удаления файла из всей истории?
- В чём разница между `git filter-branch` и `git filter-repo`?
- Как зашифровать репозиторий с помощью `git-crypt`?
- Как использовать `git replace`?
- Что делает команда `git fsck`?
- Как восстановить утерянный коммит, если его hash известен?
- Что выведет команда: ```bash git log --graph --oneline --all ```
- Как организовать Git Flow и какие команды для этого используются?
Как работает `git bisect`?
git bisect - это инструмент для поиска коммита, который вызвал регрессию (баг). Он использует алгоритм бинарного поиска.
Процесс:
- Начинаете с
git bisect start. - Отмечаете "плохой" коммит (где баг есть) с помощью
git bisect bad. - Отмечаете "хороший" коммит (где бага нет) с помощью
git bisect good. - Git переключается на коммит посередине. Тестируете, есть ли баг.
- Повторяете
git bisect badилиgit bisect goodв зависимости от результата теста. - Git сужает диапазон поиска, пока не найдет первый "плохой" коммит.
- Заканчиваете с
git bisect reset.
`git bisect` - мощный инструмент в Git, предназначенный для поиска коммита, который вызвал появление бага или изменение в коде. Он использует алгоритм бинарного поиска (binary search), что позволяет быстро найти виновный коммит в истории репозитория.
Принцип работы:
Пример использования:
Автоматизация тестирования: `git bisect` поддерживает автоматизированное тестирование с помощью скриптов. Можно передать скрипт команде `git bisect run
Принцип работы:
- Инициализация: Вы запускаете `git bisect start`.
- Определение "хорошего" коммита: Вы указываете коммит, который *точно* не содержит ошибку (например, старая версия, в которой все работало) с помощью `git bisect good
`. - Определение "плохого" коммита: Вы указываете коммит, который *точно* содержит ошибку (например, текущая версия, где вы наблюдаете проблему) с помощью `git bisect bad
`. - Бинарный поиск: Git автоматически переключает вас на коммит, находящийся посередине между "хорошим" и "плохим".
- Тестирование: Вы проверяете, присутствует ли ошибка в текущем коммите. Это может быть ручное тестирование или автоматизированный скрипт.
- Пометка коммита:
- Если ошибка *есть*, вы помечаете коммит как "плохой" с помощью `git bisect bad`.
- Если ошибки *нет*, вы помечаете коммит как "хороший" с помощью `git bisect good`.
- Повторение: Git снова переключает вас на коммит посередине оставшегося диапазона. Шаги 5 и 6 повторяются, пока не останется только один коммит между "хорошим" и "плохим".
- Идентификация виновника: Git сообщит вам коммит, который вызвал появление ошибки.
- Завершение: Вы завершаете процесс с помощью `git bisect reset`, чтобы вернуться к исходной ветке.
Пример использования:
git bisect start
git bisect good v1.0 # Коммит версии 1.0, все работало
git bisect bad v2.0 # Коммит версии 2.0, есть ошибка
# Git переключает на коммит X
# Проверяем коммит X...
# Если есть ошибка:
git bisect bad
# Если нет ошибки:
git bisect good
# (Повторяется до тех пор, пока не останется один коммит)
git bisect reset # Возвращаемся к исходной ветке
Автоматизация тестирования: `git bisect` поддерживает автоматизированное тестирование с помощью скриптов. Можно передать скрипт команде `git bisect run