7.79M

Категория:

Программное обеспечение

Похожие презентации:

Системы контроля версий

GIT. Система контроля версий

Система контроля версий

Система контроля версий Git

Система управления версиями (VCS)

Система контроля версий Git

Введение в контроль версий (семинар 3)

Система контроля версий Git

Системы управления версиями Version Control System, VCS

Система контроля версий

2.

Системы контроля версий
(Version Control System)

Система контроля версий
Неформально:
«Проект» - набор файлов с изменяющейся информацией
«Версия проекта» – актуальный для определённого временного
промежутка вариант проекта
«Система» в широком смысле – подход к контролю версий.
Например: папки с файлами
Система контроля версий:
СКВ – Система Контроля Версий | VCS – Version Control System
Инструмент для управления версиями: добавление новых версий
и переключение между существующими, ветвления…
Примеры СКВ:
«Папки с файлами»
CVS, Subversion, Perforce…
Git, Mercurial, Bazaar, Darcs…

5.

Локальные СКВ
Системы контроля версий
Локальные (Local VCS)
...
...
Локальная база данных с
возможностью доступа к
различным версиям
программы
Основной недостаток:
затруднительна совместная
разработка
Local
VCS

6.

Централизованные СКВ
Системы контроля версий
Локальные (Local VCS)
Централизованные (Centralized VCS)
...
База данных с удалённым
доступом
Основной недостаток:
единая точка отказа
Centralized
VCS

7.

Распределённые СКВ
Системы контроля версий
Локальные (Local VCS)
Централизованные (Centralized VCS)
Распределённые (Distributed VCS)
Локальные копии баз
данных изменений с
возможностью
синхронизации между собой
Distributed
VCS

8.

git
git:
Распределённая СКВ (DVCS)
«Стандарт для индустрии» (используется именно она, если нет
причин использовать другую)
Самая распространённая среди всех прочих

9.

git
Версия 3
(исправления
исправлений)
Версия 2
(исправлени
я)
Версия
1

10.

git
Репозиторий (Repository) – «папка с «проектом»», под управлением git

11.

12.

13.

git
Репозиторий (Repository) – «папка с «проектом»», под управлением git
Коммит (Commit) – «версия проекта», зафиксированный пользователем набор изменений в
«проекте»
Важные свойства:
1. Хранит историю проекта, как набор его «снимков»
2. Большинство операций над «проектом» выполняются локально, то есть затрагивают только
локальный репозиторий
3. Для любых данных в git вычисляется хеш-сумма

14.

15.

16.

Литература
Страуструп Б., Дизайн и эволюция С++
2. Страуструп Б., Язык программирования С++
3. ISO/IEC 14882:2003/2011/2014/2017
4. Чтение деклараторов и составление деклараторов по описанию
http://www.unixwiz.net/techtips/reading-cdecl.html
5. Мейерс С., Эффективное использование С++ (55 советов)
6. Мейерс С., Наиболее эффективное использование С++ (35 советов)
7. Мейерс С., Эффективный и современный С++ (42 совета для С++11/14)
8. Мейерс С., Эффективное использование STL
9. Čukić I.,Functional programming in C++
10. Abrahams D., Exception-Safety in Generic Components
Error and Exception Handling:
https://www.boost.org/community/exception_safety.html
11. Lakos J., Large Scale C++ Software Design
12. Саттер Г., Сложные задачи на С++
13. Саттер Г., Новые сложные задачи на С++
14. Э. Уильямс, Параллельное программирование в действии
15. Д. Вандервурд и др., Шаблоны С++. Полное руководство
16. Макконел С., Совершенный код
17. Git Book:
https://git-scm.com/book/en/v2
18. Rick Umali, Learn Git in a Month of Lunches
1.

17.

GitHub
Сайт: https://gitlab.com/ https://github.com/
1. Зарегистрироваться

18.

GitHub
1.
2.
Зарегистрироваться
https://github.com/
Вписать имя пользователя в таблицу
https://docs.google.com/spreadsheets/d/
1d5TROB6YbNH39X4Vlar8StmpuGEZ1vLrKVS-ZPa_POw/edit?gid=0#gid=0
4. Добавить на github ssh-ключи:
3.
5.
6.
https://spectralops.io/blog/guide-to-ssh-keys-in-gitlab/
Сделать fork репозитория:
Ссылку на реозиторий я передаю в канал группы в ТГ

19.

GitHub
1.
1 Зайти на https://github.com/

20.

GitHub
1.
2. Зарегистрироваться (нужна почта)

21.

GitHub
1.
3. Войти

22.

GitHub
1.
4. Войти в свой профиль

23.

GitHub
1.
3. Войти в свой профиль

24.

25.

GitHub
2. Вписать имя пользователя в таблицу
https://docs.google.com/spreadsheets/d/
1d5TROB6YbNH39X4Vlar8StmpuGEZ1vLrKVS-ZPa_POw/edit?gid=0#gid=0

26.

27.

GitHub
3.1. В окне терминала создать ключи (ssh-keygen)
ПЕРВАЯ ЧАСТЬ ИНСТРУКЦИИ:
https://docs.github.com/ru/authentication/connecting-to-githubwith-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

28.

GitHub
3.2. Перейти к ключам профиля: https://github.com/settings/keys

29.

GitHub
3.2. Создать новый ключ

30.

GitHub
3.3. Вставить открытую часть ключа (содержимое *.pub)

31.

32.

GitHub
4. Сделать fork репозитория:
https://github.com/Volgarenok/spbspu-labs-2024-tp-a

33.

GitHub
1.
2.
3.
4.
5.
6.
7.
Зарегистрироваться
https://github.com/
Вписать имя пользователя в таблицу
https://docs.google.com/spreadsheets/d/1PpSjdFgjsbjqz1mkCvtBMmFHJbq_8dWPDDSE7XcXxCQ/edit#gid=6665
25953
Добавить на github ssh-ключи:
https://spectralops.io/blog/guide-to-ssh-keys-in-gitlab/
Сделать fork репозитория:
Ссылку на реозиторий я передаю в канал группы в ТГ
Теперь у вас есть ссылка на СВОЙ fork.
Далее просто [FORK], то есть ссылка на него
Так же настроено взаимодействие с GitHub по ssh

34.

Лабораторные работы. НАЧАЛО
Прочитать README.md
Смотрим в самом репозитории
2. В своём fork-е включить GitHub Actions
3. Установить WSL/Ubuntu или виртуальную машину
1.
4.
5.
https://www.youtube.com/watch?v=T9vr4WTkh-g
https://ubuntu.com/tutorials/install-ubuntu-on-wsl2-on-windows-10#1-overview
Склонировать репозиторий: git clone [FORK]

35.

Лабораторные работы. НАЧАЛО
1.1. Прочитать README.md
Ссылку на реозиторий я передаю в канал группы в ТГ
ДА! ВОТ
ЭТО!

36.

Лабораторные работы.ДА!
НАЧАЛО
ЭТО
ВАЖНО!
1.2. Коротко по README
1. Один Pull Request – Одна работа
2. Работы сдаются по порядку. В одном Pull Request-е
1. Или только следующая работа
2. Или следующая работа И исправления предыдущих (если
требуется)
3. Каждая работа в отдельной ветке. Ветка должна
называться:
1. lastname.firstname/LABID
2. Pull Request должен называться так же

37.

Лабораторные работы. НАЧАЛО
1.2. Пример
namespace petrov {
struct Value {
int num;
};
void foo(Value);
}
int main()
{
petrov::Value
val{0};
petrov::foo(val);
}
void
petrov::foo(Value)
{}
Всё в namespace,

38.

39.

Лабораторные работы. НАЧАЛО
4.1. В своём fork-е включить GitHub Actions

40.

41.

Лабораторные работы. НАЧАЛО
5. Установить WSL/Ubuntu или виртуальную машину
https://www.youtube.com/watch?v=T9vr4WTkh-g
https://ubuntu.com/tutorials/install-ubuntu-on-wsl2-on-windows-10#1-overview
Ну тут
сами…

42.

43.

Лабораторные работы. НАЧАЛО
6.1. Получить ссылку для клонирования на GitHub. В СВОЁМ ФОРКЕ
ВАШ ФОРК –ЭТО КОТОРЫЙ НЕ
МОЙ РЕПОЗИТОРИЙ

44.

Лабораторные работы. НАЧАЛО
6.2. Склонировать репозиторий командой git clone [FORK] <- тут ссылка с
предыдущего шага

45.

Лабораторные работы. НАЧАЛО
6.3. Появится папка с репозиторией под управлением git

46.

Лабораторные работы. НАЧАЛО
GitHub
Fork
Main
Repository
ЕПЕРЬ ВЫ РАБОТАЕТЕ
КРАЙНЕЙ МЕРЕ СТРЕМЯ
РЕПОЗИТОРИЯМИ
А - ВАШИОДИН
- МОЙ
Сделать fork репозитория
1.
средствами GitHub
2. Склонировать репозиторий получить локальный
репозиторий (git clone)
3. Проверить, что локальный
репозиторий связан с вашим
удалённым репозиторием (git
remote get-url origin) –
должна быть ссылка на ваш
fork
Student
Remote
Repository
Clone
PC
Student
Local
Repository
Remote
?

47.

Лабораторные работы. ВЫПОЛНЕНИЕ
Читаем задание к лабораторной работе
2. ОДИН РАЗ ДЛЯ КАЖДОЙ ЛАБОРАТОРНОЙ
1. Делаем ветку ОТ master-ветки в ЛОКАЛЬНОМ репозитории
1.
git switch master //проверяем, что в мастере
2. git branch -c lastname.firstname/LABID
3. git switch lastname.firstname/LABID
1.
2.
Делаем папку под лабораторную с пустым main-ом
mkdir lastname.firstname
2. mkdir lastname.firstname/LABID
3. echo -e "int main()\n{}" > lastname.firstname/LABID/main.cpp
1.
3.
Делаем первый комит лабораторной
git add lastname.firstname/LABID/main.cpp
2. git commit -m "Initial commit for LABID"
1.
4.
Создаём ветку в своём удалённом репозитории, отправляя первую версию лабы туда
1.
3.
git push -u origin lastname.firstname/LABID
Продолжаем работу:
1. Добавляем комиты, исправляем работу (git add/git commit)
2. Отправляем изменения в удалённый репозиторий (git push [уже без параметров])

48.

Лабораторные работы
GitHub
PR
Main
Repository
Student
Remote
Repository
PR
Синхронизироваться с удалённым
репозиторием (git merge)
2. Внести изменения в локальный
репозиторий в отдельной ветке
(git branch/git commit)
3. Синхронизировать изменения со
своим удалённым репозиторием
(git push)
4. Pull Request (средствами
GitHub)
5. Pull Request в свой же, чтобы
прогнать тесты [НИКОГДА его не
вливайте]
1.
Push
PC
Student
Local
Repository
Merge
Commit

49.

«Подтягиваем master»
Синхронизируемся с основной версией проекта
Делаем один раз - добавляем основной репозиторий в remote:
git remote add upstream git@github.com:Volgarenok/spbspu-labs-2024-tp-a.git
Синхронизируем свои репозитории так, чтобы в рабочей ветке были все последние
изменения из основного репозитория:
Переключаемся на master-ветку в ЛОКАЛЬНОМ репозитории
git checkout master
Скачиваем метаданные git-а из ОСНОВГОГО репозитория
git fetch upstream
Сливаем изменения из master-а ОСВНОГО репозитория в master ЛОКАЛЬНОГО –
синхронизируемся с master-ом ОСНОВНОГО репозитория
git merge upstream/master
Синхронизируем master ЛОКАЛЬНОГО репозитория со СВОИМ УДАЛЁННЫМ
git push
Переключаемся на ветку с лабораторной
ПЕРЕД СДАЧЕЙ КАЖДОЙ
Синхронизируем рабочую ветку с ЛОКАЛЬНЫМ master-ом РАБОТЫИ ПЕРЕД
git merge master
НОВОЙ
РАБОТЫ
Синхронизируем изменения в ЛОКАЛЬНОЙ веткеРЕАЛИЗАЦИЕЙ
с соответствующей веткой
в СВОЁМ
git switch lastname.firstname/LABID
УДАЛЁННОМ репозитории
git push

50.

Работа, готовая к
принятию

51.

Работа, готовая к
принятию

52.

Практически
гарантированный
способ получить
дополнительное
задание
1. Отправить лабораторную
и получить комментарии на
неё

53.

Практически
гарантированный
способ получить
дополнительное
задание
Отправить лабораторную и
получить комментарии на
неё
2. Закрыть Merge Request и
продолжить работу в
другом, когда комментарии
остались в старом
1.

54.

55.

Практически
гарантированный
способ получить
дополнительное
задание
1.
Спамить Merge Request-ами.
Прежде, чем делать Merge
Request, убедитесь в
прохождении пайплайнов на
своей стороне

56.

Проверьте названия веток и
корректность состояния
репозитория, прежде, чем
создавать Merge Request
Дождитесь прохождения
пайплайнов и создавайте
Merge Request

57.

58.

Практически
гарантированный
способ получить
дополнительное
задание
Отправить лабораторную и
получить комментарии на
неё
2. Нажать Resolve Thread
1.

59.

60.

Практически
гарантированный
способ получить
дополнительное
задание
Отправить лабораторную и
получить комментарии на
неё
2. Нажать Resolve Thread
3. Если нажали по ошибке,
нужно открыть снова
1.
Разрешает нить обсуждения её
инициатор или выше стоящий
по иерархии (например, Team
Lead). Остальное - моветон

English Русский Правила