Git

2,487 views
2,415 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,487
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

























  • Git

    1. 1. GIT то же, что и Subversion, только круче Антон Миронов
    2. 2. Зачем нужно? “Я тоже изменял этот файл” Как бы достать старую версию файла? Когда же появился этот баг? И кто его сделал?! Как бы сделать эту фичу, а потом, если не понравится, убрать ее? “Сломался компьютер” – больше не отмазка
    3. 3. Что такое GIT? Написана Линусом Торвальдсом в 2005 году Написана для разработки ядра линукса (версия 2.6.29 имеет 11,010,647 строк кода) Написана в основном на C Открытый исходный код, бесплатная (GNU GPL V2)
    4. 4. Кому это нужно? И многим другим.
    5. 5. Термины Репозиторий место, где хранятся и поддерживаются данные Коммит фиксация изменений Ветка отдельная ветвь разработки Мерджить объединять изменения двух веток
    6. 6. Почему GIT? Очень мощная и быстрая Распределенная Полностью функциональна без соединения с интернетом Создана для нелинейной разработки, очень удобная работа с ветками
    7. 7. Мощная? ~ > 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 Очень.
    8. 8. Что делать без интернета? Изменения между версиями Полная история файла Просмотр сделанных изменений Слияние веток Переключение между ветками
    9. 9. Что значит распределенная? У каждого разработчика своя локальная копия репозитория Коммиты производятся в локальную версию Локальный репозиторий синхронизируется с удаленным специальными командами
    10. 10. Как сделать коммит? 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 делает коммит в локальный репозиторий
    11. 11. Синхронизация Получает изменения из удаленного git pull репозитория Закачивает локальные коммиты на git push удаленный сервер
    12. 12. Типичный рабочий процесс Изменили файлы, создали новые Прогнали тесты git status – увидели, какие файлы новые, какие обновленные git add . – добавили новые и обновленные файлы в индекс git commit -m “Сделал ...” – сделали коммит в локальный репозиторий Снова изменили файлы, доделали фичу, снова закоммитили git pull – скачали коммиты коллег git push – закачали свои изменения на сервер
    13. 13. ДЕМО
    14. 14. Что такое ветвление? master – основная ветка Каждая ветка – отдельный мини-репозиторий Много программистов могут работать одновременно над разными задачами в разных ветках Можно оставить задачу в ветке недоделанной, быстро переключиться в другую ветку и исправить в ней ошибку. После того как задача выполнена, сделанные изменения из ветки мерджаться в master
    15. 15. Правила хорошего тона master – ветка, которая всегда, в любой момент должна быть готова к работе Никогда не делаем новые фичи и багфиксы сразу в master, используем для этого ветки Одна фича — одна ветка Один багфикс (если предполагается длиннее двух коммитов) — одна ветка
    16. 16. Правила хорошего тона Один эксперимент — одна ветка Одна фича внутри эксперимента — ветка от ветки Всегда пишем вразумительные комментарии к коммитам После того, как фича (или багфикс) написаны, оттестированы и готовы к работе, мерджим ветку в master.
    17. 17. Коммитить в master нельзя? Можно. Когда мы точно уверены в том, что наше мелкое изменение однозначно решит проблему и не создаст новых. Когда уверены, что не понадобится потом делать багфикс для багфикса. При этом, изменения должны быть минимальными.
    18. 18. Исправление бага или добавление фичи Делаем ветку feature, вся работа по задаче происходит в ней Все тестируем Переключаемся на мастер (git checkout master) Мерджим в мастер ветку (git merge feature) Разрешаем конфликты, если были Тестируем Закачиваем на сервер (git push) Удаляем ветку (git branch -d feature)
    19. 19. ДЕМО
    20. 20. Как это выглядит в жизни?
    21. 21. Полезные команды git log Посмотреть лог коммитов git stash Зафиксировать изменения, но не коммитить git stash Восстановить изменения apply git reset Откатить все изменения до последнего коммита --hard HEAD
    22. 22. Пара рекомендаций Коммиты должны быть мелкими. Список изменений на пять экранов должен быть исключением, а не правилом. Не ленитесь создавать ветки. Это очень просто и удобно. Читайте git log, ругайте своих коллег за невразумительные описания коммитов. Тестируйте код перед тем как отправить его в master.
    23. 23. Не касался Создание репозитория Разрешение конфликтов Публикая ветки для совместной работы Разница между merge и rebase Создание меток Создание fork’ов
    24. 24. Ссылки Скачать: http://git.or.cz Почитать: http://book.git-scm.com/ Посмотреть: http://gitcasts.com/

    ×