План

1. Контроль версий.
2. Git.
3. CI/CD.
4. Рабочие процессы.
5. Сервисы хранения репозиториев исходного кода.

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

Контроль версий (англ. version control), также известный как контроль исходного кода (англ. source control), - это практика отслеживания и управления изменениями в программном коде.

Системы контроля версий (англ. version control systems, VCS) - это программные инструменты, которые помогают группам разработчиков управлять изменениями исходного кода с течением времени.

Программное обеспечение для контроля версий является неотъемлемой частью повседневной профессиональной деятельности современной команды разработчиков программного обеспечения.

Настоящая система отслеживания изменений:

Преимущества систем контроля версий

1. Полная долгосрочная история изменений каждого файла. Это означает, что имеется полная история изменения файла, когда-либо внесенными любым членом команды в любой момент.
2. Ветвление и слияние. Наличие одновременной работы нескольких членов команды не составляет труда, но даже люди, работающие самостоятельно, могут извлечь выгоду из возможности работать с независимыми потоками изменений.
3. Отслеживаемость. Возможность отслеживать каждое изменение, внесенное в программное обеспечение, и подключать его к программному обеспечению для управления проектами и отслеживания ошибок.

Контроль версий позволяет получить:

• Качество. Команды могут просматривать, комментировать и улучшать код и ресурсы друг друга.
• Ускорение. Быстрее распределяется работа, вносятся изменения и объединяются результаты изменений.
• Видимость. Понимание и стимулирование совместной работы команды для улучшения шаблонов сборки и выпуска версий.

Управление исходным кодом

Управление исходным кодом (англ. source control management, SCM) используется для отслеживания изменений в репозитории исходного кода. SCM отслеживает текущую историю изменений в базе кода и помогает разрешать конфликты при объединении обновлений от нескольких участников.

Репозиторий

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

— каталог файловой системы, в котором могут находиться файлы журналов конфигураций и операций, выполняемых над репозиторием, а также сами контролируемые файлы.

Важность инструментов управления исходным кодом

Преимущества управления исходным кодом

• Архив SCM всех изменений за время существования проекта обеспечивает ценный учет примечаний к выпускной версии проекта. Чистый и поддерживаемый журнал истории SCM можно взаимозаменяемо использовать в качестве примечаний к выпуску. Это обеспечивает понимание и прозрачность хода выполнения проекта, которыми можно поделиться с конечными пользователями или командами, не занимающимися разработкой.
• SCM сокращает коммуникационные издержки команды и увеличит скорость выпуска. Без SCM разработка идет медленнее, потому что участникам приходится прилагать дополнительные усилия для планирования непересекающейся последовательности разработки для выпуска. С помощью SCM разработчики могут независимо работать над отдельными разделами разработки функций, в конечном итоге объединяя их вместе.

Вернемся к VCS. VCS даёт возможность:

• возвращать отдельные файлы к прежнему виду;
• возвращать к прежнему состоянию весь проект;
• просматривать происходящие со временем изменения;
• определять, кто последним вносил изменения во внезапно переставший работать модуль, кто и когда внёс в код какую-то ошибку.

Можно просто копировать проект в другой каталог, такой подход часто применяется из-за своей простоты, но имеет множество недостатков:

• избыточность (дублируется весь код, а не только изменения);
• нет механизмов для распределения работы между несколькими разработчиками;
• нет данных о том что именно изменилось (обычно пишут history файл с общей информацией об изменениях).

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

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

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

В таких систем, как Apache Subversion и Perforce Helix, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него.

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

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

Локальные VCS (+/-)

Преимущества:

1. Позволяет хранить историю изменения файлов локально, без интернета.
2. Вы независимы от сторонних серверов.

Недостатки:

1. Вы можете потерять все файлы, если с вашем компьютером что-то случится.
2. Вы не можете работать в команде, поскольку репозиторий доступен только вам.

Централизованные VCS (+/-)

Преимущества:

1. Вы можете работать в команде с другими разработчиками.
2. Ваше начальство видит, чем вы занимаетесь.
3. У администратора есть четкий контроль, кто и что может делать. Администрировать центральную VCS намного проще, чем локальные на каждой машине.

Недостатки:

1. Все данные хранятся только на одном сервере. Если он выключится, то работу всей компании парализует.
2. Если с сервером что-то случится, а копий данных нет, то весь проект может быть потерян.
3. Для работы необходим хороший интернет на протяжении целого дня.

Распределенные VCS (+/-)

Преимущества:

1. Работа компании теперь не зависит от работы сервера. Если сервер отключится, то каждый сотрудник продолжит работу с локальной копией репозитория, а после загрузит ее на сервер.
2. Можно работать с несколькими удаленными репозиториями, делиться кодом с другими людьми и коллаборировать целыми компаниями.

Недостатки:

1. Отсутствие блокировок.
2. Неудобства при работе с большими репозиториями.
3. Сложно полностью удалить что-то из репозитория.
4. Сложное администрирование.
5. Сложнее в использовании и понимании, чем централизованные системы.

ПО для VC: Git

Git является самым популярным вариантом и стал синонимом "управления исходным кодом".

ПО для VC: Subversion

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

ПО для VC: Mercurial

Mercurial - это распределенная система контроля версий, которая предлагает простые возможности ветвления и объединения. Система обеспечивает быстрое масштабирование и совместную разработку с интуитивно понятным интерфейсом.

Краткая история Git

В 2005 году отношения между сообществом разработчиков ядра Linux и коммерческой компанией, которая разрабатывала BitKeeper, прекратились, и бесплатное использование утилиты стало невозможным. Это сподвигло сообщество разработчиков ядра Linux (а в частности Линуса Торвальдса — создателя Linux) разработать свою собственную утилиту, учитывая уроки, полученные при работе с BitKeeper.

Некоторыми целями, которые преследовала новая система, были:

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

Так и получился Git в 2005 году.

Отличительные особенности Git

Снимки, а не различия

Основное отличие Git от любой другой системы контроля версий (включая Subversion и её собратьев) — это подход к работе со своими данными. Концептуально, большинство других систем хранят информацию в виде списка изменений в файлах. Эти системы (CVS, Subversion, Perforce, Bazaar и т. д.) представляют хранимую информацию в виде набора файлов и изменений, сделанных в каждом файле, по времени (обычно это называют контролем версий, основанным на различиях).

Хранение данных как набора изменений относительно первоначальной версии каждого из файлов:

Подход Git к хранению данных больше похож на набор снимков миниатюрной файловой системы. Хранение данных как снимков проекта во времени:

Отличительные особенности Git

Потенциальные проблемы Git-репозитория

Каждый раз, когда вы делаете коммит, то есть сохраняете состояние своего проекта в Git, система запоминает, как выглядит каждый файл в этот момент, и сохраняет ссылку на этот снимок.

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

Отличительные особенности Git

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

Для работы большинства операций в Git достаточно локальных файлов и ресурсов — в основном, системе не нужна никакая информация с других компьютеров в вашей сети.

Вся история проекта хранится прямо на вашем локальном диске, большинство операций кажутся чуть ли не мгновенными.

Отличительные особенности Git

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

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

Механизм, которым пользуется Git при вычислении хеш-сумм, называется SHA-1 хеш. Это строка длиной в 40 шестнадцатеричных символов (0-9 и a-f), она вычисляется на основе содержимого файла или структуры каталога. SHA-1 хеш выглядит примерно так:

Является ли репозиторий Git блокчейном?

Отличительные особенности Git

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

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

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

Отличительные особенности Git

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

У Git есть три основных состояния, в которых могут находиться ваши файлы: изменён (modified), индексирован (staged) и зафиксирован (committed):

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

Три основные секциям проекта Git: рабочая копия (working tree), область индексирования (staging area) и каталог Git (Git directory). Подробнее остановимся на секциях:

• Рабочая копия является снимком одной версии проекта. Эти файлы извлекаются из сжатой базы данных в каталоге Git и помещаются на диск, для того чтобы их можно было использовать или редактировать.
• Область индексирования — это файл, обычно находящийся в каталоге Git, в нём содержится информация о том, что попадёт в следующий коммит. Её техническое название на языке Git — "индекс", но фраза "область индексирования" также работает.
• Каталог Git — это то место, где Git хранит метаданные и базу объектов вашего проекта. Это самая важная часть Git и это та часть, которая копируется при клонировании репозитория с другого компьютера.

Рабочая копия, область индексирования и каталог Git:

Базовый подход в работе с Git

1. Изменяете файлы вашей рабочей копии.
2. Выборочно добавляете в индекс только те изменения, которые должны попасть в следующий коммит, добавляя тем самым снимки только этих изменений в индекс.
3. Когда вы делаете коммит, используются файлы из индекса как есть, и этот снимок сохраняется в ваш каталог Git.

Базовые понятия (1)

Репозиторий – папка проекта, отслеживаемого Git, содержащая дерево изменений проекта в хронологическом порядке. Все файлы истории хранятся в специальной папке .git/ внутри папки проекта.

Индекс – файл, в котором содержатся изменения, подготовленные для добавления в коммит. Вы можете добавлять и убирать файлы из индекса.

Коммит – фиксация изменений, внесенных в индекс. Другими словами, коммит – это единица изменений в вашем проекте. Коммит хранит измененные файлы, имя автора коммита и время, в которое был сделан коммит. Кроме того, каждый коммит имеет уникальный идентификатор, который позволяет в любое время к нему откатиться.

Базовые понятия (2)

Указатели HEAD, ORIG_HEAD и т. д. – это ссылка на определенный коммит. Ссылка – это некоторая метка, которую использует Git или сам пользователь, чтобы указать на коммит.

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

Рабочая копия – Директория .git/ с её содержимым относится к Git. Все остальные файлы называются рабочей копией и принадлежат пользователю.

Настройки Git

Изменить настройки Git можно двумя способами:

• Отредактировать файл gitconfig (на уровне системы) или .gitconfig (глобально) или .git/config (на уровне репозитория) напрямую, то есть используя текстовый редактор.
• Воспользоваться утилитой git config.

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

1. Отслеживаемым (tracked). Об этих файлах Git знает и отслеживает изменения в них. Отслеживаемые файлы в свою очередь могут находится в следующих состояниях:
   1. Неизмененным (unmodified). То есть с момента последнего коммита в файле не было никаких изменений
   2. Измененным (modified). То есть с последнего коммита в файле были произведены какие-то изменения.
   3. Подготовленным к коммиту (staged). Это значит, что вы внесли изменения в этот файл и затем проиндексировали их, и эти изменения будут добавлены в следующий коммит.
2. Неотслеживаемым (untracked). О неотслеживаемых файлах Git не знает, поэтому изменения в них не будут добавлены в коммит. Это любые файлы в вашем рабочем каталоге, которые не входили в последний коммит и не подготовлены к текущему коммиту.

Наглядная визуализация состояний и переходов между ними:

Объекты Git

Объект – это файл, содержащий определенную информацию о репозитории и его файлах. Все объекты хранятся в директории .git/objects/. Объекты бывают трех типов:

• Blob (англ. binary large object) – большой бинарный объект, другими словами просто бинарный файл.
• Tree (англ. tree – дерево). Дерево – это такой тип графа. Объект дерева состоит из имен:
  • blob-объектов для файлов, которые лежат в данной директории, и
  • других деревьев для всех поддиректорий.
• Объект коммита. Этот объект содержит в себе имя автора коммита, время коммита и объект дерева корневой директории проекта.

Кроме этих трех объектов, важным во внутреннем устройстве Git является файл индекса.

Индекс – файл, в котором содержатся изменения, подготовленные для добавления в коммит. Во время добавления файлов командой git add:

1. Сжимает содержимое этого файла и создает blob-объект.
2. Записывает имя этого объекта в файл индекса.

Файловая система Git и команды

• рабочая директория (файловая система вашего компьютера);
• область подготовленных файлов (staging area, хранит содержание следующего коммита);
• HEAD (последний коммит в репозитории).

Файловая система Git и удаленный репозиторий

А теперь вспомним про преимущества распределённых систем контроля версий:

Что такое методология CI/CD?

CI/CD (Continuous Integration, Continuous Delivery — непрерывная интеграция и доставка) — это технология автоматизации тестирования и доставки новых модулей разрабатываемого проекта заинтересованным сторонам (разработчики, аналитики, инженеры качества, конечные пользователи и др.).

Принципы CI/CD

• Сегрегация ответственности заинтересованных сторон.
• Снижение риска.
• Короткий цикл обратной связи.
• Реализация среды.

Этапы CI/CD

CI/CD и DevOps

Преимущества CI/CD

• Инструменты CI/CD позволяют быстро выводить программный продукт на рынок, исправлять ошибки, внедрять новую функциональность.
• Автоматизация позволяет снизить нагрузку на членов команды, облегчает тестирование и уменьшает количество ошибок в каждой итерации. Главный плюс — это быстрая обратная связь.
• Гибкий план позволяет быстро перераспределять ресурсы команды на решение действительно важных задач.

Недостатки CI/CD

• Часто инструменты CI/CD воспринимаются как швейцарский нож, который может справиться с любыми задачами. При недостатке опыта это может приводить к существенному усложнению процессов в команде.
• Инструменты CI/CD не могут решить проблемы взаимодействия внутри команды, обо всём придётся договариваться.
• Все члены команды должны работать в единой экосистеме.

Инструменты для CI/CD

Gitflow

GitHub Flow

GitLab Flow

Сравнение рабочих процессов

GitLab

GitLab — веб-инструмент жизненного цикла DevOps с открытым исходным кодом, представляющий систему управления репозиториями кода для Git с собственной вики, системой отслеживания ошибок, CI/CD конвейером и другими функциями.

Gitea

Gitea - ПО для хостинга IT-проектов и совместной разработки на базе Git. Поддерживает отслеживание ошибок, вики и обзора кода. Gitea поддерживает самостоятельный хостинг, но также существует и бесплатный сервис.

GitFlic

GitFlic - первый российский сервис для хранения исходного кода и работы с ним. Основан на системе контроля версий Git.

Вопросы?

If not, just clap your hands!