Презентация - "Лекция Системы контроля версий"

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

Система контроля версий VCS
Мир без VCS
2

VCS
Система управления версиями (от англ. Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией.
Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое
Система контроля версий VCS
3

Резервные копии
Система контроля версий VCS
4

Для чего нам нужен VCS
Архивация и восстановление
Синхронизация работы с командой
Поиск “виновного”
Хранения истории разработки
Отмена изменений
Альтернативные/экспериментальные реализации

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

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

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

Что это за зверь?
Git — распределённая система управления версиями.
Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки.
8

Какие такие версии?
Версия — это состояние файла (или нескольких файлов) в какой-то конкретный момент времени.
Например, пустой файл (1), тот же файл с каким-то текстом (2) и этот же файл, в котором была исправлена опечатка (3) — три разные версии одного файла, которые были получены последовательной модификацией (изменением) файла.
9

Системы чего???
Система управления версиями — программа, позволяющая сохранять состояние файлов (те самые версии), возвращаться к ранее сохраненному состоянию, сохранять последовательность изменений внесенных в файлы, отменять или заново применять эти изменения, отслеживать авторство изменений.
10

Что там с этими версиями делают?
Разделение версий — независимые изменения одного файла.

11

Например, у нас есть файл с каким-то текстом (версия этого файла).
Файл отправляется на проверку, там обнаруживается и исправляется опечатка (получаем новую версию файла).
Независимо от этого в старый (неисправленный) файл дописывается еще что-то (получаем еще одну версию этого файла).
Т.е., на данный момент у нас есть два разных файла (две версии одного файла), которые были независимо друг от друга созданы на основе одной общей версии.

12

А при чем тут история?
История разработки — совокупность всех версий файлов, над которыми ведется работа. Историей разработки в данном случае будет список изменений:
создание файла
добавление изначального текста
исправление опечатки
добавление нового текста
объединение двух версий файла (при выполнении слияния)

13

Нелинейная история — история, в которой изменения вносятся не одно за другим последовательно, а может быть внесено несколько независимых изменений на основе одной версии файла (исправление опечатки и добавление нового текста).
Т.е. мы создаем две параллельные истории изменений файла.
14

Терминология
Репозиторий (repository) — совокупность файлов, состояние которых отслеживается, и история их изменений.
По факту, репозиторий — это проект, над которым ведется работа, и все изменения в этом проекте. Для отслеживания состояния файла его необходимо добавить в репозиторий.

15

Коммит (commit) — сохраненное состояние (версия) файлов репозитория.

16

Ветка (branch) — последовательность коммитов (история изменения состояния репозитория).
Каждый коммит в ветке имеет «родителя» (parent commit) — коммит, на основе которого был получен текущий.
В репозитории может быть несколько веток (в случаях, когда к одной версии репозитория применяется несколько независимых изменений).

17

HEAD — указатель на текущий коммит (указатель на состояние, в котором репозиторий находится на данный момент).

18

Мастер (master, main) — основная ветка репозитория, создается автоматически при создании репозитория.

19

Мердж (слияние, merge) — объединение двух или более веток. В процессе мерджа изменения с указанной ветки переносятся (копируются) в текущую.

20

Целевая ветка мерджа — ветка, изменения с которой объединяются с текущей веткой.

21

База слияния (merge base) — последний общий коммит двух веток.

22

Мердж коммит (merge commit) — коммит, который создается автоматически по завершению процесса слияния веток.
Мердж коммит содержит в себе все изменения целевой ветки мерджа, которые отсутствуют в текущей (все коммиты целевой ветки, которые начиная с базы слияния, но не включая её).

23

Слияние перемоткой (fast-forward merge) — слияние веток, при котором в текущей ветке отсутствуют новые коммиты (последний коммит текущей ветки является базой слияния).
При таком мердже текущая ветка просто переходит в состояние целевой ветки (указатель HEAD переносится на последний коммит целевой ветки).
Мердж коммит при этом не создается.

24

Слияние без перемотки (non fast-forward merge) — слияние, при котором новые коммиты (относительно базы слияния) присутствуют как в текущей, так и в целевой ветках.

25

Мердж конфликт (merge conflict) — ситуация, когда при слиянии веток в один или несколько файлов вносились независимые изменения.
В некоторых случаях (например, если изменялись разные, не пересекающиеся части одного файла) git способен самостоятельно решить, как выполнять слияние таких файлов.
Если автоматически это сделать не удалось — возникает конфликт.
В таком случае необходимо самостоятельно указать, как выполнять слияние конфликтующих версий (решить конфликт, resolve merge conflict).
Изменения, внесенные в процессе решения конфликта автоматически попадают в мердж коммит.

26

Каждый участник разработки имеет собственную копию репозитория (локальный репозиторий, local repository), в которой может вести работу независимо от остальных.
Для синхронизации внесенных изменений используется общая копия репозитория (удаленный репозиторий, remote repository), которая размещается на отдельном сервере (GitHub, GitLab, Bitbucket, собственный сервер и т.д.).
27

Наличие удаленного репозитория может быть полезным и при одиночной разработке: оно позволяет синхронизировать состояние проекта на разных компьютерах и просто сохранить проект на внешнем сервере.
28

Есть два варианта синхронизации изменений:
пулл (pull) — слияние состояния удаленного репозитория и локального (обычно — в отдельной ветке). Пулл может выполняться как для одной и той же ветки (с одинаковым именем), так и для разных. Пулл являет собою обычный мердж, но целевая ветка при этом находится не в том же репозитории, в котором выполняется пулл, а в удаленном.
29

30

пуш (push) — обратный пуллу процесс.
При пуше изменения из локального репозитория переносятся в удаленный.
Пуш обновляет состояние текущей ветки в удаленном репозитории и не является мерджем (не создает дополнительные коммиты и не может привести к конфликтам).
Если в ветке удаленного репозитория присутствуют коммиты, которых нет в локальном репозитории, сигнализируется ошибка о несовпадении истории изменений (non fast-forward merge), пуш выполнить не получится.
31

32

Нередко возникает необходимость обновить информацию о состоянии удаленного репозитория (существующих ветках и коммитах в них) без выполнения слияния (пулла).
Такой процесс называется фетчем (fetch). 
Таким образом, пулл является комбинаций фетча и мерджа: сперва обновляется информация о состоянии целевой ветки в удаленном репозитории, а затем ее изменения вливаются в текущую ветку в локальном репозитории.
33