Занятие 5 Git – система контроля версий

1. Занятие 5 Git – система контроля версий

2.

Система контроля версий (СКВ) — это система, записывающая
изменения в файл или набор файлов в течение времени и
позволяющая вернуться позже к определённой версии.
Виды:
• Локальные
• Централизованные
• Распределённые

3. Локальные системы контроля версий

Многие люди в качестве метода контроля
версий применяют копирование файлов в
отдельный каталог. Данный подход очень
распространён из-за его простоты, однако он
невероятно сильно подвержен появлению
ошибок. Можно легко забыть в каком
каталоге вы находитесь и случайно изменить
не тот файл или перезаписать его.
Для того, чтобы решить эту проблему,
программисты давным-давно разработали
локальные СКВ с простой базой данных,
которая хранит записи о всех изменениях в
файлах, осуществляя тем самым контроль
ревизий.

4. Централизованные системы контроля версий

Следующая серьёзная проблема, с которой сталкиваются
люди — это необходимость взаимодействовать с другими
разработчиками. Для того, чтобы разобраться с ней, были
разработаны централизованные системы контроля версий
(ЦСКВ). Такие системы, как CVS, Subversion и Perforce,
используют единственный сервер, содержащий все версии
файлов, и некоторое количество клиентов, которые
получают файлы из этого централизованного хранилища.
Самый очевидный минус — это единая точка отказа,
представленная централизованным сервером. Если
жёсткий диск, на котором хранится центральная БД,
повреждён, а своевременные бэкапы отсутствуют, вы
потеряете всё — всю историю проекта, не считая
единичных снимков репозитория, которые сохранились на
локальных машинах разработчиков. Локальные СКВ
страдают от той же самой проблемы: когда вся история
проекта хранится в одном месте, вы рискуете потерять всё.

5. Распределённые системы контроля версий

Здесь в игру вступают распределённые системы
контроля версий (РСКВ). В РСКВ (таких как Git,
Mercurial, Bazaar или Darcs) клиенты не просто
скачивают снимок всех файлов (состояние
файлов на определённый момент времени) —
они полностью копируют репозиторий. В этом
случае, если один из серверов, через который
разработчики обменивались данными, умрёт,
любой клиентский репозиторий может быть
скопирован на другой сервер для продолжения
работы. Каждая копия репозитория является
полным бэкапом всех данных.

6. Хранение информации в CVS Subversion

7. Хранение информации в Git

8. Почти все операции выполняются локально

Для работы большинства операций в Git достаточно локальных файлов и ресурсов —
в основном, системе не нужна никакая информация с других компьютеров в вашей
сети. Если вы привыкли к ЦСКВ, где большинство операций страдают от задержек изза работы с сетью, то этот аспект Git заставит вас думать, что боги скорости наделили
Git несказанной мощью. Так как вся история проекта хранится прямо на вашем
локальном диске, большинство операций кажутся чуть ли не мгновенными.
Для примера, чтобы посмотреть историю проекта, Git не нужно соединяться с
сервером для её получения и отображения — система просто считывает данные
напрямую из локальной базы данных. Это означает, что вы увидите историю проекта
практически моментально. Если вам необходимо посмотреть изменения, сделанные
между текущей версией файла и версией, созданной месяц назад, Git может найти
файл месячной давности и локально вычислить изменения, вместо того, чтобы
запрашивать удалённый сервер выполнить эту операцию, либо вместо получения
старой версии файла с сервера и выполнения операции локально.

9. Целостность Git

В Git для всего вычисляется хеш-сумма, и только потом происходит сохранение. В дальнейшем
обращение к сохранённым объектам происходит по этой хеш-сумме. Это значит, что невозможно
изменить содержимое файла или каталога так, чтобы Git не узнал об этом. Данная
функциональность встроена в Git на низком уровне и является неотъемлемой частью его
философии. Вы не потеряете информацию во время её передачи и не получите повреждённый
файл без ведома Git.
Механизм, которым пользуется Git при вычислении хеш-сумм, называется SHA-1 хеш. Это
строка длиной в 40 шестнадцатеричных символов (0-9 и a-f), она вычисляется на основе
содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:
24b9da6552252987aa493b52f8696cd6d3b00373
Вы будете постоянно встречать хеши в Git, потому что он использует их повсеместно. На самом
деле, Git сохраняет все объекты в свою базу данных не по имени, а по хеш-сумме содержимого
объекта.

10. Git обычно только добавляет данные

Когда вы производите какие-либо действия в Git, практически все
из них только добавляют новые данные в базу Git. Очень сложно
заставить систему удалить данные либо сделать что-то, что нельзя
впоследствии отменить. Как и в любой другой СКВ, вы можете
потерять или испортить свои изменения, пока они не
зафиксированы, но после того, как вы зафиксируете снимок в Git,
будет очень сложно что-либо потерять, особенно, если вы
регулярно синхронизируете свою базу с другим репозиторием.
Всё это превращает использование Git в одно удовольствие,
потому что мы знаем, что можем экспериментировать, не боясь
серьёзных проблем.

11.

Давайте разберём как установить и подключить Git
Установка:
1. Переходим на https://git-scm.com/download/win
2. Запускаем
3. Делаем проверку (git --version)
Подключение:
Создание аккаунта на github
Создание проекта со стороны GitHub
Скачать проект через “Get from VSC” -> Git
подробнее посмотрим состояния файлов на практике и создадим локальный
репозиторий который после запушим на удалённый сервер. Также разберём файлы
README.md и .gitignore

12. Три состояния

У Git есть три основных состояния, в которых могут находиться
ваши файлы: изменён (modified), индексирован (staged)
и зафиксирован (committed):
• К изменённым относятся файлы, которые поменялись, но ещё не
были зафиксированы.
• Индексированный — это изменённый файл в его текущей версии,
отмеченный для включения в следующий коммит.
• Зафиксированный значит, что файл уже сохранён в вашей
локальной базе.

13.

COMMIT
• Давайте добавим папку src и любой класс в эту папку. Теперь у
нас локально есть проект на котором есть папка src и какой-то
класс, но их нет в нашем удалённом репозитории. Мы намерены
этот код туда отправить, для этого мы делаем commit.
Как сделать commit:
1. Файлы которые мы хотим закомитить перевести в состояние
индексирован. (ctrl+alt+a)
2. Создаём коммит

14.

PUSH
• Для того чтобы отправить наши коммиты на удалённый
репозиторий мы должны выполнить push.
Как сделать push/forcePush:
1. Выбираем Git -> Push… (ctrl+shift+k)
2. Выполняем push

15.

PULL
• Pull используется для того чтобы выкачивать изменения из
удалённого репозитория на локальный.
Как сделать pull:
1. Выбираем Git -> Pull…

16.

Задание:
1. Изменить код и сделать commit -> push (если
понадобится, то зайти в аккаунт git)

17.

BRANCH CHECKOUT
Время разобраться что такое ветки(бранчи) и как с ними работать.
Checkout – переключиться с одной ветки на другую.
• Давайте создадим новую ветку, сделаем чекаут на неё. Добавим новый коммит и отправим в
удалённый репозиторий.
• Добавим ещё два коммита в main ветку и отправим в удалённый репозиторий. (имитация
разработки новой фичи)

18.

MERGE
Что такое мердж или слияние веток ?
Это перенос кода из одной ветки в другую. Например мы заканчиваем работу над
фичей в новой ветке и готовы добавить её в мастер ветку. Мы должны сделать
мердж нашей ветки с мастером. При это мы увидим новый коммит (где сливаются
ветки).
• Давайте смержим наши ветки.
Как сделать merge:
1. Checkout в ту ветку в которую хотим
вмержить.
2. Выбираем нужною ветку -> Merge into
current
Когда возникает merge conflict?
Конфликт возникает, когда в двух ветках была изменена одна и та же строка в файле или когда некий файл удален в
одной ветке и отредактирован в другой. Как правило, конфликты возникают при работе в команде.

19.

PULL REQUEST
Для чего нужен pull request?
В большинстве случаев пул-реквест используется для интеграции нового функционала
или для исправления бага в основной ветке проекта. Пул-реквест также содержит
короткое описание изменений и причин, по которым эти изменения вносятся.
Обычно между автором пул-реквеста и ревьюерами происходит обсуждение этих
изменений. Что-то вроде мержа, но который проверяют другие разработчики и
одобряют, или пишу что исправить.
Как сделать pull request:
1. Git -> GitHub -> Create Pull request.
2. В созданном пул реквесте назначаем ревьюера

20.

Разница MERGE и REBASE
Использовать Rebase при работе в команде только в исключительных ситуациях!

21.

CHERRY-PICK
Что такое cherry-pick ?
Команда cherry-pick позволяет скопировать коммит в другую ветку. Эта
возможность полезна в ситуации, когда нужно забрать парочку коммитов
из другой ветки, а не сливать ветку целиком со всеми внесенными в нее
изменениями.
1. Давайте создадим новую ветку test-cherry-pick
2. Добавим в неё 3 коммита и запушим в удалённый репозиторий
3. Добавим 2 коммит(из ветки test-cherry-pick) в мастер. Для этого
чекаутимся в мастер.
4. Выбираем нужный коммит RC(Right Click) -> cherry-pick
5. Мы увидим конфликт, после решения которого коммит будет добавлен
в master ветку.

22.

Дополнительная информация
Большую часть того что мы делали в Idea мы можем делать на удалённом
репозиотрии. Также всё это можно делать используя комманды в
консоли GitBash.
Если хочешь узнать больше переходи на документацию:
https://git-scm.com/book/ru/v2

23.

Сегодня мы прошли:
Что такое СКВ и их виды
Как подключить Git к проекту
Состояния файлов
Работа с ветками
Команды commit, push, pull, pull request,
merge, checkout, cherry-pick
• Решение конфликтов и разница между
merge и rebase

24.

Задание:
Создать тестовый проект, подключить к нему Git.
Потренироваться делать commit, push, pull, merge,
checkout.
Получить схожую структуру коммитов и прислать на
проверку ссылку проекта с GitHub. Проверяется умение
делать коммиты, создавать и и мержить ветки.