Инструментальные средства. Системы контроля версий

1.

Организация процесса проектирования
Программного обеспечения
Тема 4.1: Инструментальные средства.
Системы контроля версий
ст. преп. каф. ВТ
Васильев В.С.

2.

Содержание раздела
1.инструментальные средства проектирования;
2.компиляторы (оптимизирующие)/интерпретаторы:
• язык программирование (фичи, связь с оптимизацией);
• флаги компиляции/параметры интерпретатора;
• инструменты типа GodBolt/VisualVM;
3.профилировщики;
4.анализаторы кода:
• статические;
• динамические;
5.системы сборки и менеджеры пакетов;
6.системы контроля версий;
7.инструменты тестирования кода:
• отладчики?;
• средства модульного тестирования;
• интеграционного тестирования?
• нагрузочного тестирования?
• средства типа GooglePostman;
8.средства управления проектом.
2

3.

1 Системы контроля версий. Мотивация
При работе над крупным проектом часто случается:
●Несколько версий одного и того же кода:
●Под разные платформы;
●При адаптации продукта под разных заказчиков;
●Несколько программистов правят один и тот же код одновременно;
●Хотим знать кто и зачем сделал то или иное изменение в коде (кто виноват?);
●Хотим управлять изменениями (соединять работу нескольких программистов или
●Хотим структурировать код по времени (отслеживать изменения), желательно в гр
●Необходимо автоматизировать какую-то работу:
●Перед созданием новой версии продукта — запустить тесты;
●Перед загрузкой кода от программиста в общий доступ — проверить соответстви
●Ситуация — вы работаете над версией 2.0 вашей «супер-системы», заказчик пока
3

4.

2 Системы контроля версий. История
Все это можно сделать вручную — версии хранить в разных каталогах, код друг
4

5.

3 Системы контроля версий.
Распределенные и централизованные
Распределенные системы позволяют лучше масштабировать процесс разработки
Чакон Скотт, Страуб Бен Git для профессионального программиста. — СПб.: Питер,
5

6.

4 Системы контроля версий. Git. Первые шаги
Установка:
●Linux: sudo apt-get install git
●OS X: brew install git
●Windows: https://git-scm.com/downloads
Настройка (.gitconfig):
●$ git config --global user.name "Vladimir Vasilev"
●$ git config --global user.email [email protected]
Дальше можно работать через терминал, клиенты или даже встроить поддержку
6

7.

5 Системы контроля версий. Git. Облачные сервисы
Git можно развернуть локально (в своей конторе) или использовать облачные сер
Регистрируемся на любом сервисе, создаем репозиторий.
Выполняем git clone <https://link>
7

8.

6 Системы контроля версий. Git. Основные команды
8

9.

7 Системы контроля версий. Git. Ветвление
git checkout -b iss53
> 1.txt
git add .
git commit -m «comment»
git push
9

10.

7 Системы контроля версий. Git. Ветвление
Команда
Действие
git branch
вывод ветвей
git branch –v
расширенный вывод
ветвей
git branch –d
уничтожение слитой ветви
git branch –D
уничтожение еще не
слитой ветви
10

11.

8 Системы контроля версий. Git. Слияние
git checkout master
git merge iss53
Виды слияния:
●git merge;
●git rebase - работаем с веткой самостоятельно и не планируем публиковать её на сервере. Е
11

12.

9 Системы контроля версий. Git. Конфликты слияния
При слиянии могут возникнуть конфликты, при этом исходный код будет дополнен чем-т
Перед push надо разрешить конфликт — можно вручную, а можно специальными инстр
git status - определение состояния файлов;
●git log - просмотр истории;
●git fetch - обновить данные;
●git branch информация о ветках, в том числе, текущей.
Можно добавить алиасы (см. Книгу Чакона).
12
При работе с svn можно использовать git: https://habr.com/ru/company/wapstart/blog/159477/

13.

Никаких ветвей
•Используется в новых проектах, рабочего кода
еще не имеющего.
•Коммиты идут в основную ветку
•Основная ветка может периодически пребывать в
нестабильном состоянии
Плюсы:
•Легко использовать
•Низкий входной барьер
•Не надо учиться ветвлению или слиянию
Минусы:

14.

Ветви всегда
•Проекты с жестким контролем и управлением
•Пользователь создает ветвь на каждую задачу
•По завершении работы над ветвью некто
(программист, его напарник или его начальник)
проверяет ветвь и организует слияние
Плюсы
•Порядок и организованность
•Основная ветка всегда будет стабильной
Минусы
•Программисты сильно отделены друг от друга

15.

Ветви по необходимости
•Компромиссный вариант
•Пользователи создают отдельные ветви для
крупных задач
•Периодически ветви вливаются в основную
•Основная ветвь всегда должна быть стабильной
(компилироваться, проходить тесты)
•Размер изменения от одного коммита должен
быть в пределах разумного (удобным для оценки
и рассмотрения)
•Речь о создании ветви заходит, когда за один
коммит задачу не решить

16.

Master+Develop
Две основных ветви – главная (Master) и ветвь
разработки (Develop)
•Существуют все время жизни проекта
•Головной указатель главной ветви показывает на
последнюю стабильную версию
•Изменения регулярно вносятся в ветвь
разработки; главная ветвь меняется реже.
•Стабильный и перепроверенный код из ветви
разработки может вливаться в главную ветвь
•Слияние чаще всего происходит через
специальную промежуточную ветвь релиза

17.

Master+Develop

18.

Ветви поддержки
•Ветви релиза. Отпочковываются от ветви
развития, вливаются в ветвь развития и главную
ветвь. Когда разработчик полностью уверен в
готовности последней серии исправлений, из
ветви разработки выделяется ветвь релиза; после
контрольных тестов и последних исправлений она
вливается в главную ветвь (развитие стабильной
версии) и ветвь развития (на случай исправлений в
последнюю минуту).
•Ветви быстрых исправлений (hotfix). Частный
случай ветвей релиза; возникают вне планов и

19.

Master+Develop+Production
Новая ветвь Production
•В эту ветвь выносятся срезы главной ветви,
соответствующие мажорным и минорным
выпускам продукта.
•Возможность получить быстрый доступ к версии
продукта с заданным номером может оказаться
довольно полезной в поиске и исправлении
ошибок.

20.

Master+Develop+Production

21.

10 Системы контроля версий. Gitflow
Gitflow - методология работы с Git, определяет, какие ветки нужно создать и как произво
21

22.

11 Системы контроля версий. Gitflow
22

23.

12 Системы контроля версий. Gitflow
Gitflow - методология работы с Git, определяет, какие ветки нужно создать и как произво
Установка:
●Linux: apt-get install git-flow
●Windows: установить git.
Создать ветки вручную и следить за ними также или использовать:
git flow init
23

24.

13.1 Удаление файлов из git-репозитория. Мотивация
Лишние файлы:
1.Занимают место — ограничения в Bitbucket -2Гб, GitHub - 1 Гб).
2.Затрудняют восприятие проекта.
3.Уменьшают скорость работы.
Решить проблему можно так:
Использовать .gitignore;
Создать новый репозиторий (без мусора);
Использовать специальные инструменты:
Git-filter-branch;
BFG Repo-Cleaner.
24

25.

13.2 Удаление файлов из git-репозитория.
Работа с git-filter-branch
1. Клонировать репозиторий:
git clone https://bitbucket.org/rrrfer-admin/test_git_filter
cd test_git_filter
2. Выполнить команду по удалению ненужных файлов:
git filter-branch --tree-filter 'rm -f images/*.jpg' HEAD
git filter-branch --tree-filter 'rm -rf folder1’ HEAD
3. Выполнить команду по очистке от мусора:
git reflog expire --expire=now --all && git gc --prune=now --aggressive
4. Выполнить команду по обновлению историй веток и тегов:
git push origin --force --all
git push origin --force –tags
5. Сохранить изменения:
git push
25

26.

13.3 Удаление файлов из git-репозитория.
Работа с BFG Repo-Cleaner
0. Установить JRE, скачать bfg.version.jar: https://rtyley.github.io/bfg-repo-cleaner/
1. Клонировать репозиторий:
git clone --mirror https://bitbucket.org/rrrfer-admin/test_git_filter
cd test_git_filter
2. Выполнить команду по удалению ненужных файлов:
java –jar bfg-1.13.0.jar –delete-files ‘*.jpg’ --no-blob-protection
3. Выполнить команду по очистке от мусора:
git reflog expire --expire=now --all && git gc --prune=now --aggressive
4. Сохранить изменения:
git push
26

27.

14 Работа с чужим репозиторием
Цель — склонировать чужой репозиторий, работать с ним как со своим (ведь Push в чужо
Если хотите помочь чужому проекту — правильнее использовать Pull Request.
В bitbucket есть встроенный механизм импорта (при создании репозитория).
В github есть механизм fork, который помимо прочего сохранит информацию об ответвле
«Особые механизмы» не позволяют переносить репозиторий. А что если вы развернули
27

28.

15 Системы контроля версий. Литература
Модель ветвления Gitflow: https://bitworks.software/2019-03-12-gitflow-workflow.html
●Пожалуйста, перестаньте рекомендовать Git Flow: https://habr.com/ru/company/flant/blog
●Чакон Скотт, Страуб Бен Git для профессионального программиста. — СПб.: Питер, 20
●Документация на .gitignore: https://git-scm.com/docs/gitignore
●Официальный сайт BFG Repo-Cleaner: https://rtyley.github.io/bfg-repo-cleaner/
●Репозиторий с мусором для эксперимента: https://bitbucket.org/rrrfer-admin/test_git_filter
●Git: Восстановление удаленного коммита/ветки: https://pro-prof.com/forums/topic/git-восс
●Git: Использование модулей (submodule): https://pro-prof.com/forums/topic/git-использова
●Git: импорт части репозитория (subtree): https://pro-prof.com/forums/topic/git-subtree
●Пример использования хуков (hooks) в git: https://habr.com/ru/post/75063/
28