В самой популярной системе контроля версий нужно хорошо разбираться. Проверьте знание команд git, ответив на 11 каверзных вопросов.
Последние опросы на Stack Overflow показывают, что более 70% разработчиков используют git для ПО с открытым исходным кодом и для коммерческих продуктов. Преимущества этой VCS для командной работы сложно переоценить.
Вопрос 1. В чем разница между fork, branch и clone?
Сложность: ⭐⭐
- Fork – удаленная копия репозитория на сервере, отличная от оригинала. Это даже не git-концепция, а, скорее, политико-социальная идея.
- Clone – это не то же самое, что и fork. Клон удаленного репозитория располагается локально. Фактически при клонировании копируются все данные, включая историю коммитов и существующие ветки.
- Branch, или создание ветки, – это способ внести изменения в проект и объединить их в итоге с остальным кодом. Ветка является частью репозитория.
Источник: stackoverflow.com
Вопрос 2. В чем разница между pull request и branch?
Сложность: ⭐⭐
- Branch – это просто отдельная версия кода.
- Pull request – этот попытка добавить собственные изменения в репозиторий другого владельца. Чтобы сделать такой запрос, нужно взять чей-то проект, создать отдельную ветку, а затем предложить слить ее с остальными.
Источник: stackoverflow.com
Вопрос 3. Объясните разницу команд git pull и git fetch?
Сложность: ⭐⭐
Простыми словами, git pull = git fetch + git merge.
- Когда вы делаете pull, git старается автоматически выполнить всю работу за вас. Этот процесс зависит от контекста, git объединит все коммиты и обновит ту ветку, на которой вы в данный момент находитесь. Слияние осуществляется автоматически, без вашего участия. Если система обнаружит несопоставимые различия, произойдет конфликт.
- Когда вы делаете fetch, git просто собирает все коммиты целевой ветки, которых у вас еще нет, и сохраняет их локально. Объединения веток при этом не происходит. Это очень полезно, если вам необходимо актуальное состояние репозитория, но оно может нарушить вашу работу. Ознакомившись с изменениями, вы можете слить их в вашу ветку с помощью merge.
Источник: stackoverflow.com
Вопрос 4. Как отменить предыдущий коммит?
Сложность: ⭐⭐⭐
Предположим, у вас сложилась следующая ситуация. Указатель HEAD находится в C, а (F) – это текущее состояние ваших файлов.
(F)
A-B-C
↑
master
Откатиться к предыдущему состоянию можно с помощью группы команд git reset с разными флагами.
• Чтобы полностью отменить коммит, используйте
git reset --hard HEAD~1
Теперь HEAD указывает на B. Флаг --hard стирает все изменения ваших файлов до состояния B.
• Чтобы отменить коммит, но сохранить сделанные в нем изменения, просто выполните
git reset HEAD~1
Так мы передвигаем HEAD на один коммит назад (на B), но оставляем файлы в том состоянии, в котором они находятся. git status покажет, что файлы соответствуют фиксации C.
• Чтобы отменить коммит и сохранить все проиндексированные файлы, используйте
git reset --soft HEAD~1
Вызовите git status и убедитесь, что в индексе git находятся те же файлы, что и раньше.
Источник: stackoverflow.com
Вопрос 5. Что такое git cherry-pick?
Сложность: ⭐⭐⭐
Команда git cherry-pick используется для перенесения отдельных коммитов из одного места репозитория в другое, обычно между ветками разработки и обслуживания. Этот механизм отличается от привычных команд git merge и git rebase, которые переносят коммиты целыми цепочками.
git cherry-pick <commit-hash>
Источник: stackoverflow.com
Вопрос 6. Расскажите о преимуществах forking workflow.
Сложность: ⭐⭐⭐
Работа через форки принципиально отличается от других популярных методов организации командной разработки. Вместо того чтобы использовать один серверный репозиторий в качестве центральной кодовой базы, здесь каждый разработчик получает свой собственный репозиторий. Чаще всего эта модель применяется в общедоступных open source проектах.
Основное преимущество forking workflow заключается в том, что все изменения вносятся без загрязнения истории проекта. Разработчики делают push в собственные репозитории, а доступ к центральному есть только у менеджера.
Когда обновление готово к интеграции, программист делает pull-запрос в главный репозиторий, а менеджер одобряет и вносит его.
Источник: atlassian.com
Вопрос 7. В чем разница между HEAD, рабочим деревом и индексом?
Сложность: ⭐⭐⭐
- Рабочее дерево (рабочая директория, рабочее пространство) – это дерево исходных файлов, которые вы можете видеть и редактировать.
- Индекс (область подготовленных файлов, staging area) – это один большой бинарный файл .git/index, в котором указаны все файлы текущей ветки, их SHA1, временные метки и имена. Это не отдельная директория с копиями файлов.
- Указатель HEAD – это ссылка на последний коммит в текущей извлеченной ветке.
Источник: stackoverflow.com
Вопрос 8. Расскажите о gitflow-организации рабочего процесса.
Сложность: ⭐⭐⭐
Модель gitflow использует две параллельные «долгие» ветки для хранения истории проекта: master и develop.
- Master – это полностью готовое к релизу состояние со всеми пройденными тестами.
- Hotfix – ветки обслуживания, или хотфиксы, которые используются для быстрых патчей. Они очень похожи на feature, но вместо develop-ветки базируются на master.
- Develop – ветка, в которой объединяются и тестируются все отдельные разработки. После прохождения проверок они отправляются в master.
- Feature – отдельная ветка для каждой новой функциональности, изменения из которой отправляются в develop.
Источник: atlassian.com
Вопрос 9. Когда следует использовать git stash?
Сложность: ⭐⭐⭐
git stash берет ваши изменения, подготовленные и неподготовленные к фиксации, сохраняет их для последующего использования и убирает из рабочей области.
$ git status On branch master Changes to be committed: new file: style.css Changes not staged for commit: modified: index.html $ git stash Saved working directory and index state WIP on master: 5002d47 our new homepage HEAD is now at 5002d47 our new homepage $ git status On branch master nothing to commit, working tree clean
Это полезно в ситуации, когда вы внезапно поняли, что последний коммит следует изменить, но уже начали другую работу в той же самой ветке.
# спрятать все, что вы уже успели сделать $ git stash save # внести необходимые изменения # добавить их в последний коммит $ git add -u $ git commit --ammend # вернуться к работе $ git stash pop
Источник: atlassian.com
Вопрос 10. Как удалить файл из git, но оставить его в файловой системе компьютера?
Сложность: ⭐⭐⭐⭐
Если вы не будете осторожны с использованием команд git add, то можете случайно добавить в индекс файлы, которые там быть не должны. git rm может удалить их из индекса, но одновременно сотрет и из файловой системы (рабочего дерева). Это не всегда то, что требуется.
Используйте вместо этого git reset:
git reset filename echo filename >> .gitingore # добавьте файлы в .gitignore
Команда git reset <path> противоположна git add <path>.
Источник: codementor.io
Вопрос 11. Когда следует использовать git rebase вместо git merge?
Сложность: ⭐⭐⭐⭐⭐
Предназначение этих команд git – интеграция изменений из одной ветки в другую, но делают они это по-разному.
Предположим, у вас сложилась такая ситуация:
A <- B <- C [master] ^ \ D <- E [branch]
После обычного мержа репозиторий будет выглядеть так:
A <- B <- C ^ ^ \ \ D <- E <- F
А после git rebase– так:
A <- B <- C <- D <- E
Rebase указывает на то, что коммиты нужно буквально перенести со старого места на новое.
Что выбрать?
- Если вы сомневаетесь, то используйте обычное слияние.
- Выбор между merge и rebase обусловлен тем, какой вы хотите видеть историю коммитов: линейной или ветвящейся.
Учитывайте следующие факторы:
- Если ветка, в которую вы хотите внести изменения доступна для других разработчиков (например, в open source проекте), не используйте rebase. Эта команда удаляет ветку целиком и приводит к рассинхронизации копий репозиториев.
- Представляет ли исходная ветка ценность? Некоторые команды работают по принципу «одна функция – одна ветка», при этом ветка идентифицирует последовательность коммитов. В модели «один разработчик – одна ветка» в этом нет особой необходимости, так как автор коммита известен.
- Не захотите ли вы вдруг отменить слияние? Возврат rebase значительно затруднен по сравнению с обычным слиянием, а иногда даже невозможен.
Источник: stackoverflow.com
Перевод статьи Alex Ershov: 11 Painful Git Interview Questions You Will Cry On
Комментарии