1. GIT
то же, что и Subversion, только круче
Антон Миронов

2. Зачем нужно?
“Я тоже изменял этот файл”
Как бы достать старую версию файла?
Когда же появился этот баг?
И кто его сделал?!
Как бы сделать эту фичу, а потом, если не понравится,
убрать ее?
“Сломался компьютер” – больше не отмазка

4. Что такое GIT?
Написана Линусом
Торвальдсом в 2005 году
Написана для разработки
ядра линукса (версия
2.6.29 имеет 11,010,647
строк кода)
Написана в основном на C
Открытый исходный код,
бесплатная (GNU GPL V2)

5. Кому это нужно?
И многим другим.

6. Термины
Репозиторий
место, где хранятся и поддерживаются данные
Коммит
фиксация изменений
Ветка
отдельная ветвь разработки
Мерджить
объединять изменения двух веток

7. Почему GIT?
Очень мощная и быстрая
Распределенная
Полностью функциональна без соединения с интернетом
Создана для нелинейной разработки, очень удобная
работа с ветками

8. Мощная?
~ > git
add clone imap-send request-pull
am commit init reset
annotate config instaweb revert
apply describe log rm
archive diff merge send-email
bisect external-chdiff mergetool shortlog
blame fetch mv show
branch filter-branch name-rev show-branch
bundle format-patch publish-branch stash
checkout fsck pull status
cherry gc push submodule
cherry-pick get-tar-commit-id rebase svn
chmerge grep relink tag
citool gui remote whatchanged
clean help repack wtf
Очень.

9. Что делать без интернета?
Изменения между версиями
Полная история файла
Просмотр сделанных изменений
Слияние веток
Переключение между ветками

10. Что значит
распределенная?
У каждого разработчика своя локальная копия
репозитория
Коммиты производятся в локальную версию
Локальный репозиторий синхронизируется с удаленным
специальными командами

11. Как сделать коммит?
SVN GIT
svn add file git add file
svn rm file git rm file
svn mv file git mv file
svn commit git commit
Важно: git commit делает коммит в локальный репозиторий

12. Синхронизация
Получает изменения из удаленного
git pull
репозитория
Закачивает локальные коммиты на
git push
удаленный сервер

13. Типичный рабочий
процесс
Изменили файлы, создали новые
Прогнали тесты
git status – увидели, какие файлы новые, какие обновленные
git add . – добавили новые и обновленные файлы в индекс
git commit -m “Сделал ...” – сделали коммит в
локальный репозиторий
Снова изменили файлы, доделали фичу, снова закоммитили
git pull – скачали коммиты коллег
git push – закачали свои изменения на сервер

14. ДЕМО

15. Что такое ветвление?
master – основная ветка
Каждая ветка – отдельный мини-репозиторий
Много программистов могут работать одновременно над
разными задачами в разных ветках
Можно оставить задачу в ветке недоделанной, быстро
переключиться в другую ветку и исправить в ней ошибку.
После того как задача выполнена, сделанные изменения
из ветки мерджаться в master

16. Правила хорошего тона
master – ветка, которая всегда, в любой момент должна быть
готова к работе
Никогда не делаем новые фичи и багфиксы сразу в master,
используем для этого ветки
Одна фича — одна ветка
Один багфикс (если предполагается длиннее двух коммитов) —
одна ветка

17. Правила хорошего тона
Один эксперимент — одна ветка
Одна фича внутри эксперимента — ветка от ветки
Всегда пишем вразумительные комментарии к коммитам
После того, как фича (или багфикс) написаны, оттестированы и
готовы к работе, мерджим ветку в master.

18. Коммитить в master
нельзя?
Можно.
Когда мы точно уверены в том, что наше мелкое
изменение однозначно решит проблему и не создаст
новых.
Когда уверены, что не понадобится потом делать багфикс
для багфикса.
При этом, изменения должны быть минимальными.

19. Исправление бага или
добавление фичи
Делаем ветку feature, вся работа по задаче происходит в ней
Все тестируем
Переключаемся на мастер (git checkout master)
Мерджим в мастер ветку (git merge feature)
Разрешаем конфликты, если были
Тестируем
Закачиваем на сервер (git push)
Удаляем ветку (git branch -d feature)

20. ДЕМО

21. Как это выглядит в жизни?

22. Полезные команды
git log Посмотреть лог коммитов
git stash Зафиксировать изменения, но не коммитить
git stash
Восстановить изменения
apply
git reset Откатить все изменения до последнего
коммита
--hard HEAD

23. Пара рекомендаций
Коммиты должны быть мелкими. Список изменений на
пять экранов должен быть исключением, а не правилом.
Не ленитесь создавать ветки. Это очень просто и удобно.
Читайте git log, ругайте своих коллег за
невразумительные описания коммитов.
Тестируйте код перед тем как отправить его в master.

24. Не касался
Создание репозитория
Разрешение конфликтов
Публикая ветки для совместной работы
Разница между merge и rebase
Создание меток
Создание fork’ов

25. Ссылки
Скачать: http://git.or.cz
Почитать: http://book.git-scm.com/
Посмотреть: http://gitcasts.com/