Теоретический кусочек к повествованию о не всегда очевидных, но очень важных моментах в git

1. ПРО GIT
МАРТ 2016

2. НЕМНОГО
ТЕОРИИ

3. GIT
3
• Распределенная система управления версиями
• Локальные репозитории vs удаленные репозитории
• Настройки в текстовых файлах
• Ветки
• Набор утилит командной строки
• Ваша любимая графическая оболочка
• Ваш любимый веб-интерфейс (Gitlab, Stash, …)

4. ОБЪЕКТЫ GIT
4
• Blob — хранение содержимого файла
• Дерево — хранение списка файлов
• Коммит — хранение состояния файлов
• Тег — метка коммита

5. ИЗМЕНЕНИЯ, КОММИТЫ, УКАЗАТЕЛИ
5
• Любой снимок доступен по хешу коммита, в котором он был
сделан
• Ветка — это просто указатель на верхний коммит в некоторой
цепочке коммитов.
• HEAD — хранит указатель на текущую ветку

6. ТЕГИ
6
• Позволяют фиксировать важные моменты в истории
репозитория
• Задавать названия релизов, версии библиотек и т. д.
• Пример: аннотированный тег может содержать release notes
релиза, к которому он относится

7. ЛУЧШИЕ
ПРАКТИКИ

8. КОДРЕВЬЮ: ЗАЧЕМ?
8
• Оценить изменения в ветке-кандидате относительно главной
ветки
• Сообщить команде о предстоящих изменениях
• Найти потенциальные ошибки
• Оценить документацию
• Поправить codestyle

9. ОСМЫСЛЕННЫЕ COMMIT MESSAGES
9
• Отвечают на вопрос «что сделал?»
• Позволяют другим понять, зачем в код были внесены изменения
• Упрощают кодревью
• Помогают написать release notes
• Помогают интегрироваться с багтрекерами
• git commit -m ‘Summary’ -m ‘Description’

10. MERGE VS REBASE
10
• Задача: объединить изменения одной ветки с другой веткой.
Например, влить в локальную ветку изменения из удаленной
• Узкое место: если делать git pull и git push, то при
определенных условиях git будет создавать бессмысленные
merge-коммиты
• Даже когда вы делаете git pull orgin master, git создаст мерж-
коммит, если в удаленном master’е были чужие изменения
• Чем плохо? Загрязняет историю коммитов
• Что делать? Всегда git pull --rebase orgin master

11. MERGE VS REBASE: СЛИЯНИЕ ВЕТОК
11
• Аналогично: для того, чтобы слить разные ветки вместо git
merge feature делаем git rebase feature
• Находясь в фича-ветке, вливаем в нее master: git rebase master
• Находясь в master’е, вливаем фича-ветку: git rebase feature
• После того, как был произведен rebase всех необходимых
изменений, можно делать git push.

12. ИНТЕРАКТИВНЫЙ REBASE
12
• GIT — это не система создания бэкапов!
• Одно из правил хорошего тона — сквош коммитов, которые по одиночке
не несут никакого смысла, но вместе представляют собой некоторое
осмысленное действие
• Зачем? Проще разруливать конфликты между своей веткой и одним
коммитом из другой, чем между своей веткой и пятьюдесятью коммитами
• Что еще? Поменять коммиты местами. Удалить коммиты, как будто их и не
было
• Примечание 1. Будьте осторожны, производя rebase в удаленных
репозиториях
• Примечание 2. Будьте осторожны при использовании --force
git rebase -i

13. ХУКИ
13
• Хуки — это скрипты, которые срабатывают при возникновении
некоторых событий — commit, push, merge и т. д.
• Локальные (client-side) и удаленные (server-side)
• Как использовать:
• автопроверки (формат commit-message, codestyle и другие
соглашения)
• оповещение внешних систем (коммент в багтрекере, запуск
автотестов и т. д.)
.git/hooks

14. ЧТО ЧИТАТЬ
14
• Git How To: https://githowto.com/ru
• Pro Git: https://git-scm.com/book/ru/v2
• Правила хорошего тона при оформлении коммитов: https://
habrahabr.ru/company/Voximplant/blog/276695/
• Как использовать git rebase: https://habrahabr.ru/post/161009/