После лекции вы сможете объяснить устройство истории Git, собрать осмысленный коммит, создать ветку, объединить изменения и обменяться ими с другим разработчиком. Для работы достаточно знакомого по предыдущим занятиям терминала: Bash, Zsh или Git Bash. Команды демонстрации выполняются по порядку в одном терминале; блоки, помеченные как справочные, выполнять подряд не нужно.
Главный вопрос занятия: какие данные и какие указатели меняет команда? Это помогает предсказывать результат вместо запоминания рецептов.
Представьте лабораторную работу: вчера программа работала, сегодня вы добавили новую возможность, а товарищ одновременно исправил старую ошибку. Нужно выяснить, что изменилось, вернуть работоспособную версию и сохранить обе полезные доработки. Копии папок с названиями final, final2 и final_really быстро перестают помогать.
Система контроля версий хранит историю состояний проекта и связи между ними. Она позволяет сравнивать версии, сопровождать параллельные направления разработки и связывать изменения с объяснениями. Хорошая история отвечает на вопросы «что?» и «почему?». Сами сообщения пишет человек: Git не знает мотивов автора.
| Система | Организация работы | Практическое следствие |
|---|---|---|
| Subversion, SVN | Центральный репозиторий и рабочие копии | Публикация коммита требует доступа к серверу; локальные правки возможны без него |
| Git | Распределённые репозитории | Коммиты, локальная история и ветки доступны без сервера |
| Mercurial | Распределённые репозитории | Похожая возможность автономной работы при другой модели команд и ветвления |
У обычного полного клона Git есть собственная база объектов и полученная история. Существуют также сокращённые и частичные клоны — к ним вернёмся во второй лекции. В команде часто выбирают один репозиторий главным по соглашению, хотя формат Git не требует единственного центра.
Git и GitHub — разные вещи. Git работает локально. GitHub, GitLab и другие платформы добавляют размещение репозиториев, обсуждения, права доступа и проверки. Аккаунт на платформе не нужен для первых экспериментов.
Git появился в 2005 году после прекращения прежних условий бесплатного использования BitKeeper разработчиками Linux. В 2002 году проект Linux начал использовать BitKeeper. Эти даты описывают разные события. Главными требованиями к новой системе были скорость, распределённость и работа с большим числом параллельных изменений. История Git.
Вопрос аудитории: что можно сделать без интернета — изменить файл, создать коммит, посмотреть локальную историю, отправить коммит коллеге?
Коммит фиксирует снимок отслеживаемого содержимого, подготовленного к сохранению. Разницу между двумя снимками Git может вычислить и показать как diff. Неизменившееся содержимое переиспользуется. На уровне хранения Git также применяет сжатие и может упаковывать объекты с дельтами: это оптимизация хранения, которая не отменяет модель снимков. Модель Git.
В Git есть четыре основных типа объектов:
| Объект | Что содержит |
|---|---|
blob |
Содержимое файла; имени файла внутри blob нет |
tree |
Имена записей, режимы и ссылки на объекты содержимого и поддеревьев |
commit |
Ссылку на корневое дерево, родителей, данные автора и коммитера, время и сообщение |
tag |
Данные аннотированной метки и ссылку на помечаемый объект |
Один blob может использоваться под разными именами. Коммит знает о снимке через корневое дерево. Blob хранит содержимое, а не путь к текущему файлу на диске. Объекты Git.
Идентификатор вычисляется из типа, размера и содержимого объекта. Он не является порядковым номером или временной меткой. У коммита на идентификатор влияют и дерево, и родители, и метаданные: два коммита с одинаковыми файлами могут иметь разные идентификаторы.