More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
Similar to Git for you
Similar to Git for you (20)
More from Pavel Alexeev
Git for you
- 1. GIT If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now. © Joel Spolsky. © Pavel Alexeev, Grigel Constantin, Igor Redkin. 2016
- 3. Коротко о главном • Локальные коммиты, распределённость • Куча настроек: цвета, предпочтения, хранение, лимиты ресурсов, алиасы • Из коробки: подсветка diff, конверт line endings, visual merge. • Отдельные commit и push/pull - работа над “future”, staging, stash, merge, rebase, cherry-pick, --amend. • Удобная передача коммитов, в том числе по почте без прямой доступности git patch/git am/git format-patch • Xdelta алгоритм хранения - быстро, компактно • Open source! 3
- 4. Краткая история Git Основные требования 1. Скорость 2. Простота дизайна 3. Поддержка нелинейной разработки (тысячи параллельных веток) 4. Полная распределённость 5. Возможность эффективной работы с такими большими проектами, как ядро Linux (как по скорости, так и по размеру данных) 6. Поддержка различных workflow 4
- 7. Отличия/Требования к Git 1. Почти все операции — локальные 2. Git следит за целостностью данных 3. Чаще всего данные в Git только добавляются 4. Три состояния 7
- 10. Множество опциональных настроек 1. git config 2. Виды конфигурации Общие для всех пользователей системы (git config --system) Настройки для конкретного пользователя (git config --global) Конфигурационный файл в каталоге Git’а (git config) 10
- 12. Any Workflow 12 Subversion-Style Workflow ● very common ● especially for transition Integration Manager Workflow ● Integration manager, lead ● Many may clone and contribute ● Pull/merge requests Dictator and Lieutenants Workflow ● For massive projects (kernel.org) ● Delegate part of responsibility
- 13. Расширенный и удобный. Приступим. 13
- 14. Удобный инструмент. Staging 14 svn commit != git commit
- 15. ● svn tag != git tag. True read only. ● branch не создаёт директорий - указатель на коммит ● tag: ○ Annotated ○ Lightweight Tags Удобный инструмент. Бранчи и теги (метки, tag) 15
- 16. Удобный инструмент. Бранч на фичу 16
- 18. Удобный инструмент. Merge fast forward 18
- 20. Интерактивный rebase 20 Зачем? # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell
- 22. Продолжаем знакомиться. Revert 22 ● На стадии stage: git checkout (git reset --hard отмена всего) ● Если локально коммит был: git rebase -i ● Push уже состоялся: git revert HEAD ○ Любая ревизия, относительно/абсолютно ○ Можно диаппозон ○ Можно указать сообщение или открыть редактор $ git revert HEAD --no-edit [master 45fa96b] Revert "Oops, we didn't want this commit" 1 files changed, 1 insertions(+), 1 deletions(-) $ git hist * 45fa96b 2011-03-09 | Revert "Oops, we didn't want this commit" (HEAD, master) [Pavel]
- 23. А всё ли смерджили из бранчей? 23 ● git branch --merged master lists branches merged into master ● git branch --merged lists branches merged into HEAD (i.e. tip of current branch) ● git branch --no-merged lists branches that have not been merged ● git merge-base command to find the latest common commit between the two branches
- 24. ● Отслеживание изменений во внешних директориях ● Зависимость на уровне кода, а не артефактов ● Возможность изменять несколько, “сбор дерева” ● Отслеживается добавления подмодуля. Файл .gitmodules. Отслеживается также бранч и версия ● Контент отдельно ● Можно использовать обновление (merge/fetch/pull/push) отдельно или для проекта целиком: git clone --recursive Подмодули (подпроекты) 24 $ git submodule add https://github.com/chaconinc/DbConnector Cloning into 'DbConnector'... remote: Counting objects: 11, done. remote: Compressing objects: 100% (10/10), done. remote: Total 11 (delta 0), reused 11 (delta 0) Unpacking objects: 100% (11/11), done. Checking connectivity... done. $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes to be committed: new file: .gitmodules new file: DbConnector $ git commit -am 'added DbConnector module' [master fb9093c] added DbConnector module 2 files changed, 4 insertions(+) create mode 100644 .gitmodules create mode 160000 DbConnector $ git clone https://github.com/chaconinc/MainProject $ cd MainProject $ cd DbConnector/ $ ls $ $ git submodule init $ git submodule update Cloning into 'DbConnector'... … Submodule path 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b29bc' $ git clone --recursive https://github.com/chaconinc/MainProject Cloning into 'MainProject'... … Submodule 'DbConnector' (https://github.com/chaconinc/DbConnector) registered for path DbConnector' Cloning into 'DbConnector'... ... Submodule 'DbConnector': checked out 'c3f01dc8862123d317dd46284b05b6892c7b29bc'
- 26. Достаточно email для передачи изменений 26
- 27. GUI под различные OS 27 Windows, Linux, Mac Free examples Mac Windows, Mac
- 28. И много ещё полезного... 28 ● Настраиваемая подсветка (diff/merge) ● Настройка просмотра истории ● git show - показ коммита и его изменений ● Показ статистики изменений ● git bisect - поиск внесённой ошибки ● git cherry-pick - точечный перенос коммитов ● Хуки на сервере ● git mergetool - использование любого инструмента слияния (Xcode, Idea, kDiff, meld) ● Настройка алиасов команд
- 29. Система менеджмента кода и ревью Популярность инструмента растёт Сервисы вроде https://github.com/, https://bitbucket.org Интеграция со множеством систем (Jira) Системы ревью кода. Использование бранчей. Gerrit, Phabricator, Gitosis, Gitlab, Review Board... 29 Об этом подробнее в следующей части презентации
- 30. Использованные материалы 1. http://zzet.org/learn-git/lection-1.html?full#21 2. http://git-scm.com/about/ 3. http://www.slideshare.net/MikhailVasilyev/git-subversion-12256851 4. http://www.slideshare.net/demiazz/git-14357600 5. http://www.slideshare.net/oelifantiev/git-27341307 6. http://www.slideshare.net/opedge/git-33590567 7. http://www.slideshare.net/Unomano/ss-32855881 8. http://www.slideshare.net/phpdevby/git-11216260 9. https://www.atlassian.com/git/articles/10-years-of-git/ 10. https://git-scm.com/download/gui/linux 30
- 32. Workflow. Существует 2 основных ветки: master и dev. master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент. dev — ветка, над которой в данный момент работает команда. В начале разработки master и dev ветки идентичны.
- 34. Workflow. Step 1 Когда программист начинает работу над новым дефектом / функционалом, он должен переключиться на ветку dev и получить ее последнюю версию. git checkout dev git pull origin dev К примеру, разработчик хочет начать исправлять дефект страницы аутентификации. Номер ошибки на Github — 1234. Разработчик должен создать новую ветку из dev git checkout -b 1234-bug-login 1234-bug-login это только пример. Первым словом должен быть номер дефекта, вторым — bug / feature, а дальше — описание проблемы.
- 35. Workflow. Step 2 Далее разработчик продолжает работу локально: делает изменения, коммиты и т.д. Commit-cообщения должны содержать номер ошибки и техническое описание git add ...list of files... git commit -m "#1234" Итак, разработка окончена, и теперь необходимо отправить изменения на Github git push origin 1234-bug-login Все изменения теперь в репозитории. После этого разработчику необходимо обновить свою ветку из dev, чтобы иметь возможность слить ее без конфликтов.
- 36. Workflow. Step 3 Сперва необходимо получить последнюю версию dev ветки git checkout dev git pull origin dev И затем влить все изменения, которые произошли в dev ветке, в свою ветку (1234-bug- login) git checkout 1234-bug-login git rebase dev git push -f origin 1234-bug-login
- 37. Workflow. Step 4 DEV branch to Master branch with team lead firewall
- 38. Workflow. Step 5. Testing & Release Как только 1234-bug-login попадает в dev, Jenkins (система непрерывной интеграции) автоматически обновляет dev сервер из dev ветки. QA могут начинать тестировать и как итог подтвердить или переоткрыть задачу. Если регрессионное тестирование успешно закончено, можно обновлять production сервер, при этом берется последний пакет (тот, на котором проходило тестирование), и именно он устанавливается на production сервер.
- 39. Code Review
- 40. Code Review
- 42. Git as a service
- 43. Git as a service Name GIT SVN HG Code Review Issue Tracker Bitbucket Codebas e GitHub GitLab
- 44. Git as a local development process
- 45. GitLab and all the rest 45 Name Language Activity License Gitlab Ruby Yes Open Source Stash Java Yes Comercial Gerrit Java Yes Apache License 2.0 Gitblit Java Yes Apache License 2.0
- 47. Git backup process ● Each copy is full backup ● Distributed storage ● File-system copy ● Git bundle ● Gcrypt remote ● Mirror remote ● Live mirror ● Backup As A Service
- 48. Git integration with Atlassian products
- 49. Git Integration with everything
- 51. Git with zero downtime Git-SVN mirror of existing Subversion repository. Push to Git or commit to Subversion at your convenience
- 52. Convert your existing Subversion project to Git Import processes huge repositories, preserves all the data and history
- 53. ADD TO BITBUCKET SERVER SVN Mirror for Atlassian Bitbucket Server (formerly known as Atlassian Stash) will pull your existing Subversion project right into Bitbucket Server, as a one-time import or full- featured bi-directional mirror.
- 54. Price and Cloud VS Independence 54
Editor's Notes
- Автор блога http://www.joelonsoftware.com/. В прошлом один из руководителей разработки Microsoft Excel.
- передача изменений без сервера Меньше ошибок из-за неполных, незавершённых изменений интерактивный ребэйз Open source! - фиксы, коммьюнити, куча туториалов, подсказок
- http://www.opennet.ru/opennews/art.shtml?num=44040 Релиз ядра Linux 4.5 В новую версию принято около 13 тысяч исправлений от примерно 1500 разработчиков, размер патча - 70 Мб (изменения затронули 11589 файлов, добавлено 1146727 строк кода, удалено 854589 строк). Около 45% всех представленных в 4.5 изменений связаны с драйверами устройств, примерно 17% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 14% связано с сетевым стеком, 4% - файловыми системами и 3% c внутренними подсистемами ядра.
- Каждый может настроить под себя. git config - инструмент конфигурирования. Не просто конфиг файлы. Валидация. Подсказки.
- Subversion style Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine. Integration Manager Workflow Integration manager (team lead, reviewer) — a single person who commits to the 'blessed' repository. Many may clone and contribute. One made decision future ready Pull/merge requests This is the type of development model often seen with open source or GitHub repositories. Dictator and Lieutenants Workflow For more massive projects (kernel.org) Delegate part of projects responsibility
- Обратите внимание - первая часть локальное использование! Не надо ничего кроме гита. SVN так не умеет.
- Push|pull, staging
- svn tag != git tag branch - одельное измерение Отдельная сущность (subcommand). Указатель на коммит, а не директория (ветка) разработки. Annotated (-a, --annotate) - Вы также можете подписывать свои метки с помощью GPG (-s, --sign) Легковесная метка — это ещё один способ отметки коммитов. В сущности, это контрольная сумма коммита, сохранённая в файл — больше никакой информации не хранится. Для создания легковесной метки не передавайте опций -a, -s и -m:
- Бранчи локальны и легки. Тег также. При этом не происходит “копирования” как в SVN. Отдельная сущность.
- Отдельная команда. Отмена уже закоммиченного и запушенного коммита. Не надо вручную делать reverse-merge.
- http://stackoverflow.com/questions/226976/how-can-i-know-in-git-if-a-branch-has-been-already-merged-into-master By default this applies to only the local branches. The -a flag will show both local and remote branches, and the -r flag shows only the remote branches.
- Вы хотите чтобы проекты были отдельными (например разные ответственные, модель релизов) При этом вы хотите зависеть от файлов, а не от внешних бинарных артефактов таких как JAR, WAR. Например над ним вы тоже работаете. Собираете для теста вместе. Сам по себе модуль не клонируется. Вместо контента только файл .gitmodules! Обратите внимание, факт добавления модуля также коммититься и отслеживается в истории. Но не контент другого репозитория! Notice the 160000 mode for the DbConnector entry. That is a special mode in Git that basically means you’re recording a commit as a directory entry rather than a subdirectory or a file. https://git-scm.com/book/en/v2/Git-Tools-Submodules $ git submodule foreach 'git stash' $ git submodule foreach 'git checkout -b featureA' $ git diff; git submodule foreach 'git diff' Алиасы рекурсивно: $ git config alias.sdiff '!'"git diff && git submodule foreach 'git diff'" $ git config alias.spush 'push --recurse-submodules=on-demand' $ git config alias.supdate 'submodule update --remote --merge' А ещё есть git subtree - https://habrahabr.ru/post/75964/
- Бранчи локальны и легки. Тег также. При этом не происходит “копирования” как в SVN. Отдельная сущность.
- Если нет возможности коммитить в удалённый репозиторий. Если команды привыкли использовать получение патчей по почте. Git am применит патч на той стороне. Сохранив авторство и коммит-сообщение.
- GitEye от CollabNet, тех, кто делает сборки SVN. Только на https://git-scm.com/download/gui/linux представлено 13 основных.
- filter-branch git cherry-pick - определённого коммита из другой ветки
- origin — это имя по умолчанию, которое Git присваивает серверу, с которого вы склонировали
- SVN has no local repo. Therefore svn checkin is used to push your changes into the remote repo. GIT has a local repo. Commit creates a new 'version' in your local and your local only. Git push is then used to send this changeset into the remote.
- Отлично! Ветка с решенными конфликтами в репозитории. Теперь разработчик делает Сreate Pull Request из 1234-bug-login в dev ветку при помощи Github. Так же необходимо разместить ссылку на задачу (#1234) в описании Pull Request. Pull Request отправлен, любой разработчик может сделать code review, написать комментарии, уточнения и т.д. Комментарии должны быть исправлены и отправлены на Github обычным способом. Pull Request обновится автоматически Иногда, исправления занимают некоторое время, и другие разработчики уже слили свои ветки с dev. В этом случае есть 2 варианта: - кнопка Merge pull request на Github активна. Это означает, что изменения других разработчиков не конфликтуют с текущими изменениями, и ничего дополнительного делать не требуется. - кнопка Merge pull request неактивна. Необходимо вернуться к пункту 4) и заново слить и отправить изменения из dev ветки в 1234-bug-login.