Your SlideShare is downloading. ×

Git

2,216
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,216
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
29
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

























  • Transcript

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