Образовательный центр программирования и высоких технологий

1.

Минск, 2020 г.
ОБРАЗОВАТЕЛЬНЫЙ ЦЕНТР
ПРОГРАММИРОВАНИЯ И ВЫСОКИХ
ТЕХНОЛОГИЙ
Введение в работу с GIT

2.

Что такое VCS
VCS – version control system.
Система контроля версий — это система, записывающая изменения
файла или набора файлов в течение времени и позволяющая
вернуться позже к определённой версии.

3.

Типы VCS
1. Локальные (RCS)
2. Централизованные (CVS, Subversion)
3. Распределенные(Git, Mercurial, BitKeeper)

4.

Локальная VCS

5.

Централизованная VCS

6.

Распределенная VCS

7.

Преимущества GIT
• Скорость
• Простая архитектура
• Хорошая поддержка нелинейной разработки (тысячи параллельных
веток)
• Полная децентрализация
• Возможность эффективного управления большими проектами,
такими как ядро Linux (скорость работы и разумное использование
дискового пространства)

8.

Основные идеи
• Версии – это снимки, а не diff.
• Практически все операции выполняются локально
• Целостность. SHA-1 хеш высчитывается для всего.
• После добавления данных в гит, их тяжело (но можно) потерять.
• Полная поддержка git – только в терминале.
• Все файлы могут находится в одном из следующих состояний –
сохраненные (committed, измененные (modified), припасенные
(staged))

9.

Основные идеи
Версии – это снимки, а не diff.
Это означает, что github не хранит разницу между версиями файлов, а
сохраняет полный снимок каждой версии. Таким образом, вы можете легко
переключаться между разными версиями и видеть, как выглядел ваш проект
в определенный момент времени.

10.

Изменения это снимки а не разность (diff)

11.

Основные идеи
Практически все операции выполняются локально.
Это означает, что вы не нуждаетесь в постоянном подключении к
интернету, чтобы работать с github. Вы можете создавать,
редактировать, коммитить и откатывать изменения на своем
локальном репозитории, а затем синхронизировать его с удаленным
репозиторием, когда у вас будет доступ к сети.

12.

Основные идеи
Целостность. SHA-1 хеш высчитывается для всего.
Это означает, что github использует алгоритм хеширования SHA-1,
чтобы присваивать уникальный идентификатор каждому объекту в
репозитории, будь то файл, папка, коммит или ветка. Это
гарантирует, что никто не сможет подделать или повредить ваши
данные, и вы всегда сможете проверить, что вы работаете с
правильной версией.

13.

Основные идеи
После добавления данных в гит, их тяжело (но можно) потерять.
Это означает, что github очень надежно хранит ваши данные, и вы не
должны беспокоиться о том, что они будут случайно удалены или
перезаписаны. Однако, если вы совершите какую-то ошибку, например,
удалив нужный файл или ветку, или сделав нежелательный коммит, вы все
равно сможете восстановить их, используя специальные команды гита,
такие как git reset, git revert, git reflog и т.д.

14.

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

15.

Основные идеи
Все файлы могут находится в одном из следующих состояний –
сохраненные (committed, измененные (modified), припасенные (staged)).
Это означает, что в любой момент времени вы можете определить, в каком
состоянии находятся ваши файлы относительно вашего репозитория.
Сохраненные файлы – это те, которые уже были добавлены в репозиторий
и не имеют никаких изменений. Измененные файлы – это те, которые были
отредактированы, но еще не были припасены для коммита. Припасенные
файлы – это те, которые были отмечены для включения в следующий
коммит. Вы можете использовать команды git status, git diff и git add, чтобы
управлять состояниями файлов и подготовить их к коммиту.

16.

Состояния файлов

17.

Конфигурация Git
• git config [--<layer>]
<key>
layers:
• --system
• --global
• --local
$ git config --global user.name "John Doe"
$ git config $--global user.email [email protected]
$ git config --global core.editor nano
$ git config --global credential.helper store

18.

Help
$ git help [command]
$ man git-<verb> //Linux command
$ git <verb> -h | --help

19.

Начало работы
В рабочей папке выполняем команды:
• git init
• git add README.md (либо перечисляем файлы, либо пишем . )
• git commit -m "first commit"
• git branch -M main
• git remote add origin https://github.com/{ссылка на ваш
репозиторий}.git
• git push -u origin main

20.

Жизненный цикл файлов

21.

Жизненный цикл файлов
Неотслеживаемый (Untracked). Это значит, что файл еще не был добавлен в
репозиторий гита и гит не знает о его существовании. Чтобы добавить файл в
репозиторий, вы должны использовать команду git add <имя файла>. После
этого файл перейдет в статус Неизмененный (Unmodified).
Неизмененный (Unmodified). Это значит, что файл уже есть в репозитории
гита, но вы не вносили в него никаких изменений с момента последнего
коммита. Если вы отредактируете файл, он перейдет в статус Измененный
(Modified). Если вы захотите удалить файл из репозитория, вы должны
использовать команду git rm <имя файла>. После этого файл перейдет в статус
Неотслеживаемый (Untracked).

22.

Жизненный цикл файлов
Измененный (Modified). Это значит, что вы изменили файл, но еще не
приготовили его к коммиту. Чтобы приготовить файл к коммиту, вы должны
использовать команду git add <имя файла>. После этого файл перейдет в
статус Подготовленный (Staged). Если вы захотите отменить свои изменения,
вы можете использовать команду git checkout -- <имя файла>. После этого
файл вернется в статус Неизмененный (Unmodified).
Подготовленный (Staged). Это значит, что вы отметили файл для включения в
следующий коммит. Чтобы сделать коммит, вы должны использовать команду
git commit -m "<сообщение коммита>". После этого файл перейдет в статус
Неизмененный (Unmodified).

23.

Добавление в staging
Добавить изменения в staging
$ git add <filename> [<filename>]
Можно использовать wildcards:
$ git add *.py
‘.’ Применяется для того чтобы добавить все изменения:
$ git add .
* - для замены любой строки символов звёздочка
? - для замены любого одиночного символа знак вопроса.

24.

Просмотр состояния GIT
Текущее состояние (изменения, ветка)
$ git status
Параметры команды:
$ git status --help
Посмотреть изменения файла:
$ git diff [<filename>]

25.

Сохраняем изменения. Commit
Сохранение изменений из staging в репозиторий. Откроется
текстовый редактор.
$ git commit
Если не очень хочется отдельно писать сообщение для коммита:
$ git commit -m “my first commit”
Сохранить все:
$ git commit -a

26.

Работа с изменениями
Передвинуть файл из staged в modified
$ git reset HEAD <filename>
Передвинуть файл в состояние unchanged. (Отмена всех изменений):
$ git checkout -- <filename>
Удалить файл из рабочей директории.
--cached чтобы пометить к удалению но не удалять физически:
$ git rm [ --cached] <filename>
Добавить изменения из staging в последний комит:
$ git commit --amend

27.

Просмотр истории
$ git log
commit 5f5b7b4b1e1684a9b428dce1bfcf86085ccf4b6f (HEAD -> issue-1)
Author: Maxim_Belov <[email protected]>
Date: Sat Sep 21 22:11:19 2023 +0300
20
Add view for GET user credentials
commit ac1b0e4a0613fab175a7a99858e128d17412fbf3 (origin/issue-1)
Author: Maxim_Belov <[email protected]>
Date: Tue Sep 17 23:19:06 2023 +0300
Add db settings

28.

Ветки

29.

Версии и коммиты как снимки

30.

Структура коммита

31.

Указатели: HEAD, ветки, тэги

32.

Указатели: HEAD, ветки, тэги
Коммиты или снимки. Это белые прямоугольники с уникальными кодами,
например, 98ca9, 34ac2, f30ab. Каждый коммит представляет собой полный
снимок состояния вашего проекта в определенный момент времени. Каждый
коммит имеет уникальный идентификатор, который вычисляется с помощью
алгоритма хеширования SHA-1. Этот идентификатор позволяет гиту отличать
коммиты друг от друга и проверять их целостность.

33.

Указатели: HEAD, ветки, тэги
Версии снимков. Это бирюзовые прямоугольники под кодами коммитов,
например, A, B, C. Они показывают, какие версии снимков были созданы в
процессе разработки вашего проекта. Вы можете дать своим снимкам любые
имена, которые вам удобны, или использовать автоматические номера
версий, например, v1.0, v2.0 и т.д.

34.

Указатели: HEAD, ветки, тэги
Стрелки между коммитами. Они показывают, как происходит переход от
одного коммита к другому. Каждый новый коммит ссылается на
предыдущий коммит, создавая цепочку истории вашего проекта. Вы можете
перемещаться по этой цепочке, используя разные команды гита, например,
git checkout, git reset, git revert и т.д.
Ветки. Это красные прямоугольники над кодами коммитов, например,
master. Они показывают, как вы можете создавать разные варианты развития
вашего проекта, не затрагивая основную линию. Ветки позволяют вам
экспериментировать с новыми функциями, исправлять ошибки, совмещать
изменения и т.д. Вы можете создавать, переключаться, сливать и удалять
ветки, используя разные команды гита, например, git branch, git switch, git
merge, git branch -d и т.д.

35.

Указатели: HEAD, ветки, тэги
HEAD. Это желтый прямоугольник, указывающий на ветку master. Он
показывает, на какой ветке или коммите вы сейчас находитесь. HEAD всегда
указывает на последний коммит в текущей ветке. Вы можете изменить
положение HEAD, используя разные команды гита, например, git checkout, git
reset, git rebase и т.д.

36.

Работа с ветками
Список веток:
$ git branch
Создание веток:
$ git branch branch_name
Переключение на ветку:
$ git checkout branch_name
Создание ветки и переключение на нее:
$ git checkout -b my_branch_name

37.

Создание ветки

38.

Переключение на новую ветку

39.

Коммит изменений
$ touch other_file
$ git commit -a -m “my branch commit”

40.

Слияние (merge)

41.

42.

Метод Fast-forward
$ git checkout master
$ git merge hotfix
Updating f42c576..3a0874c
Fast-forward
Эта картинка иллюстрирует метод “Fast-forward” в гите, системе контроля версий. В этом
методе, если между текущей веткой и веткой, которую нужно слить (в данном случае,
“master” и “hotfix”), нет разветвленных коммитов, то гит просто переместит (или “быстро
перемотает”) указатель текущей ветки на последний коммит ветки, которая сливается.

43.

Метод recursive
$ git checkout iss53
$ touch iss53.py
$ git commit -a -m 'fix issue 53'
Эта картинка иллюстрирует метод “recursive” в гите, системе контроля версий. Он
показывает, как вы можете исправить проблему, помеченную как “iss53”, и слить ее
обратно в ветку “master”. Команды, перечисленные на картинке, используются для
переключения на ветку проблемы, создания нового файла с именем iss53.py и фиксации
изменений с сообщением, говорящим, что проблема 53 исправлена.

44.

$ git checkout master
$ git merge iss53

45.

$ git merge iss53

46.

Merge конфликты
$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Графический инструмент решения конфликтов - git mergetool

47.

$ git mergetool
This message is displayed because 'merge.tool' is not configured.
See 'git mergetool --tool-help' or 'git help config' for more details.
'git mergetool' will now attempt to use one of the following tools:
opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge
ecmerge p4merge araxis bc3 codecompare vimdiff emerge
Merging:
index.html
Normal merge conflict for 'index.html':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (opendiff):

48.

Долгоживущие ветки

49.

Долгоживущие ветки
Эта картинка показывает концепцию долгоживущих веток в системах
контроля версий, в частности, в гите. Диаграмма разделена на две части:
верхняя часть показывает отдельные коммиты (C1-C7) на разных ветках
(master, develop, topic), а нижняя часть иллюстрирует, как эти ветки и
коммиты интегрируются.

50.

Ветки для задач

51.

Удаленные репозитории
(remotes)

52.

Удаленные ветки

53.

Удаленные ссылки
Эта картинка показывает типичный
сценарий в системе контроля версий гита,
когда локальный репозиторий и удаленный
репозиторий не синхронизированы. В
верхней части картинки есть удаленный
репозиторий, размещенный на
“git.ourcompany.com” с коммитами до
“31b8e”. Однако кто-то еще запушил новый
коммит “190a3” в ветку master на
удаленном репозитории. В нижней части
картинки, на “My Computer”, вы скачали
коммиты до “f4265” и сделали два
дополнительных коммита “a38de” и “893cf”.
Ваша локальная ветка master опережает
origin/master, но отстает от обновленной
ветки master на удаленном репозитории.

54.

Работа с удаленными репозиториями
Список remotes:
$ git remote –v
Синхронизироваться с удаленным репозиторием(забрать изменения):
$ git fetch [<repository_name>]
$ git fetch origin
Чтобы сохранить работу в удаленном репозитории:
$ git push [<remote>] [your_branch[:remote_branch]]
git pull == git fetch + git merge

55.

Fetch
Эта картинка иллюстрирует операцию
“fetch” в гите, системе контроля версий. Она
показывает, как вы можете получать новые
коммиты с удаленного репозитория в
локальный репозиторий, но не сливать их с
рабочей веткой.

56.

Git Workflow
56

57.

58.

Информация, тренировка
• https://git-scm.com/book/en/v2 - pro git (Scott Chacon and Ben
Straub)
• https://learngitbranching.js.org/ - интерактивная обучалка