5 Занятие (Git)

Содержание

Слайд 2

Система контроля версий (СКВ) — это система, записывающая изменения в файл

Система контроля версий (СКВ) — это система, записывающая изменения в файл или набор

файлов в течение времени и позволяющая вернуться позже к определённой версии.
Виды:
Локальные 
Централизованные 
Распределённые 
Слайд 3

Локальные системы контроля версий Многие люди в качестве метода контроля версий

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

Многие люди в качестве метода контроля версий применяют

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

Централизованные системы контроля версий Следующая серьёзная проблема, с которой сталкиваются люди

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

Следующая серьёзная проблема, с которой сталкиваются люди — это необходимость

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

Распределённые системы контроля версий Здесь в игру вступают распределённые системы контроля

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

Здесь в игру вступают распределённые системы контроля версий

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

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

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

Слайд 7

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

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

Слайд 8

Почти все операции выполняются локально Для работы большинства операций в Git

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

Для работы большинства операций в Git достаточно

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

Целостность Git В Git для всего вычисляется хеш-сумма, и только потом

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

В Git для всего вычисляется хеш-сумма, и только потом происходит

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

Git обычно только добавляет данные Когда вы производите какие-либо действия в

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

Когда вы производите какие-либо действия в Git,

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

Давайте разберём как установить и подключить Git Установка: 1. Переходим на

Давайте разберём как установить и подключить Git
Установка: 1. Переходим на https://git-scm.com/download/win
2. Запускаем


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

Три состояния У Git есть три основных состояния, в которых могут

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

У Git есть три основных состояния, в которых могут находиться

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

Давайте добавим папку src и любой класс в эту папку. Теперь

Давайте добавим папку src и любой класс в эту папку. Теперь

у нас локально есть проект на котором есть папка src и какой-то класс, но их нет в нашем удалённом репозитории. Мы намерены этот код туда отправить, для этого мы делаем commit.

Как сделать commit: 1. Файлы которые мы хотим закомитить перевести в состояние индексирован. (ctrl+alt+a)
2. Создаём коммит

COMMIT

Слайд 14

Для того чтобы отправить наши коммиты на удалённый репозиторий мы должны

Для того чтобы отправить наши коммиты на удалённый репозиторий мы должны

выполнить push.

Как сделать push/forcePush: 1. Выбираем Git -> Push… (ctrl+shift+k)
2. Выполняем push

PUSH

Слайд 15

Pull используется для того чтобы выкачивать изменения из удалённого репозитория на

Pull используется для того чтобы выкачивать изменения из удалённого репозитория на

локальный.

Как сделать pull: 1. Выбираем Git -> Pull…

PULL

Слайд 16

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

Задание:
Изменить код и сделать commit -> push (если понадобится, то

зайти в аккаунт git)
Слайд 17

Время разобраться что такое ветки(бранчи) и как с ними работать. Checkout

Время разобраться что такое ветки(бранчи) и как с ними работать.
Checkout –

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

BRANCH CHECKOUT

Слайд 18

Что такое мердж или слияние веток ? Это перенос кода из

Что такое мердж или слияние веток ? Это перенос кода из одной ветки в другую.

Например мы заканчиваем работу над фичей в новой ветке и готовы добавить её в мастер ветку. Мы должны сделать мердж нашей ветки с мастером. При это мы увидим новый коммит (где сливаются ветки).

MERGE

Давайте смержим наши ветки.
Как сделать merge:
1. Checkout в ту ветку в которую хотим вмержить. 2. Выбираем нужною ветку -> Merge into current

Когда возникает merge conflict?
Конфликт возникает, когда в двух ветках была изменена одна и та же строка в файле или когда некий файл удален в одной ветке и отредактирован в другой. Как правило, конфликты возникают при работе в команде.

Слайд 19

Для чего нужен pull request? В большинстве случаев пул-реквест используется для

Для чего нужен pull request?
В большинстве случаев пул-реквест используется для интеграции

нового функционала или для исправления бага в основной ветке проекта. Пул-реквест также содержит короткое описание изменений и причин, по которым эти изменения вносятся. Обычно между автором пул-реквеста и ревьюерами происходит обсуждение этих изменений. Что-то вроде мержа, но который проверяют другие разработчики и одобряют, или пишу что исправить.

PULL REQUEST

Как сделать pull request:
1. Git -> GitHub -> Create Pull request. 2. В созданном пул реквесте назначаем ревьюера

Слайд 20

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

Разница MERGE и REBASE

Использовать Rebase при работе в команде только в

исключительных ситуациях!
Слайд 21

Что такое cherry-pick ? Команда 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 ветку.

CHERRY-PICK

Слайд 22

Большую часть того что мы делали в Idea мы можем делать

Большую часть того что мы делали в Idea мы можем делать

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

Дополнительная информация

Слайд 23

Сегодня мы прошли: Что такое СКВ и их виды Как подключить

Сегодня мы прошли:
Что такое СКВ и их виды
Как подключить Git к

проекту
Состояния файлов
Работа с ветками
Команды commit, push, pull, pull request, merge, checkout, cherry-pick
Решение конфликтов и разница между merge и rebase