Для чего нужны системы контроля версий и какими они бывают. Почему именно Git

Представим ситуацию:
Контроль версий ПО осуществляется копированием файлов в другой каталог, как правило добавляя текущую дату к названию каталога.

Потенциальные проблемы:
Случайное изменение не тех файлов, или изменение файлов не в том каталоге либо ...

Потенциальные проблемы:
Копирование файлов не туда, куда надо было, и в результате затирание нужных файлов

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

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

Функции системы контроля версий
●
хранение нескольких версий одного и того же документа (история версий);
●
хранение истории разработки;
●
при необходимости возвращение к более ранним версиям документа
(отмена изменений);
●
определение, кто и когда сделал изменение (поиск «виновного»);
●
совмещение изменений сделанных разными разработчиками
(синхронизация работы команды);
●
реализация альтернативных/экспериментальных вариантов проекта.

Области применения систем контроля версий
●
Разработка программного обеспечения - хранение исходных кодов разрабатываемой программы.
●
Области, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов:
○
Как пример - Википедия ведёт историю изменений для всех её статей, используя методы, аналогичные тем, которые применяются в системах управления версиями.

История развития
Source Code Control System (SCCS) — первая система управления версиями, разработанная в Bell Labs в 1972 году Марком Рочкиндом (
англ.
Marc J.
Rochkind) для компьютеров IBM System/370

Классификация VCS по способу хранения данных
1.
Локальные системы контроля версий
Например: rcs.
2.
Централизованные системы контроля версий
Например: CVS, Subversion и Perforce.
3.
Децентрализованные системы контроля версий
Например: Git, Mercurial, Bazaar, Darcs.

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

Локальные системы контроля версий
Основываются на простой базе данных в которой хранятся изменения нужных файлов.

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

Распределённые системы контроля версий
●
У каждого пользователя свой вариант (возможно не один) репозитория
●
Присутствует возможность добавлять и забирать изменения из любого репозитория

Распределённые системы контроля версий
Преимущества:
●
Так как каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных, то в случае сбоев на сервере, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных.

Распределённые системы контроля версий
●
Возможность работать с несколькими удалёнными репозиториями, таким образом, можно одновременно работать по- разному с разными группами людей в рамках одного проекта.
Так, в одном проекте можно одновременно вести несколько типов рабочих процессов, что невозможно в централизованных системах.

Ежедневный цикл работы с Git
●
Обновление репозитория и рабочей копии git pull
●
Добавление файла в проект git add newFile.cpp
●
Коммит git commit –m “описание того, что сделано”
●
Передача изменений во внешний репозиторий git push

Стадии разработки ПО
Пре-альфа (Pre-alpha (pa))
●
Начальная стадия разработки.
●
Характеризуется большими изменениями в функционале и большим количеством ошибок.
●
Может включать в себя не весь спектр функциональных возможностей программы
(разработка дизайна, анализ требований, собственно разработка приложения, а также отладка отдельных модулей).
●
Pre-alpha релизы не покидают отдела разработки ПО.

Стадии разработки ПО
Альфа (Alpha(a))
●
Соответствует этапу завершения разработки нового функционала.
●
Возможно добавление новых функциональных возможностей.
●
Стадия внутреннего тестирования.
●
Характеризуется высокой активностью по тестированию внутри подразделения разработки ПО и устранению ошибок.
●
Программы на данной стадии могут применяться только для ознакомления с будущими возможностями.

Стадии разработки ПО
Бета (Beta (b))
●
Стадия публичного тестирования.
●
Это первый релиз, который выходит за пределы отдела разработки ПО.
●
Программы этого уровня могут быть использованы другими разработчиками программного обеспечения для испытания совместимости.
●
На этом этапе принимаются замечания от пользователей по интерфейсу продукта и прочим найденным пользователями ошибкам и неточностям.

Стадии разработки ПО
Бета (Beta (b))
●
Программы этого этапа могут содержать достаточно большое количество ошибок.
●
Публичное тестирование производится на страх и риск пользователя, производитель не несёт никакой ответственности за ущерб, причинённый в результате использования бета-версии. (Пользуясь этим некоторые производители уходят от ответственности, предоставляя пользователям только бета-версии продукта).

Стадии разработки ПО
Релиз-кандидат (Release Candidate (rc))
●
Пре-релиз — стадия-кандидат на то, чтобы стать стабильной.
●
Весь функционал реализован и проведено комплексное тестирование.
●
Все найденные на предыдущих этапах критические ошибки исправлены.
●
Существует вероятность выявления ещё некоторого числа ошибок, не замеченных при тестировании.
●
На этом этапе могут вноситься изменения в документацию и конфигурации продукта.

Стадии разработки ПО
Релиз (Release to manufacturing или Release to marketing (rtm))
●
Промышленное издание — стабильная версия программы, которая готова к тиражированию.
●
ПО соответствует всем требованиям качества, и готово для массового распространения.
●
RTM не определяет способа доставки релиза (сеть или носитель) и служит лишь для индикации того, что качество достаточно для массового распространения.
●
RTM предшествует общей доступности (GA), когда продукт выпущен для общественности.

Стадии разработки ПО
Финальный релиз General availability (ga)
●
Этап завершения всех работ по коммерциализации продукта.
●
Продукт полностью готов к продажам через веб или на физических носителях.
●
End of life (eol) – работы по развитию и поддержке продукта завершены.

Стадии разработки ПО
Critical Fix (CF) - экстренный выпуск либо новой сборки приложения, либо патча, исправляющих критическую ошибку в приложении.
●
Новая функциональность в приложения с помощью CF не добавляется.
Пакет Обновлений (Maintenance Pack (MP)) - плановый выпуск новой сборки приложения, с целью добавления новых возможностей в продукт и исправления найденных ошибок.

Первоначальная настройка Git https://gitforwindows.org
- скачать и установить
Первоначальная настройка Git
Теперь, когда Git установлен в вашей системе, хотелось бы сделать кое-какие вещи, чтобы настроить среду для работы с Git'ом под себя. Это нужно сделать только один раз — при обновлении версии Git'а настройки сохранятся. Но вы можете поменять их в любой момент, выполнив те же команды снова.

Первоначальная настройка Git
Имя пользователя
Первое, что вам следует сделать после установки Git'а, — указать ваше имя и адрес электронной почты. Это важно, потому что каждый коммит в Git'е содержит эту информацию, и она включена в коммиты, передаваемые вами, и не может быть далее изменена:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Первоначальная настройка Git
Проверка настроек
Если вы хотите проверить используемые настройки, можете использовать команду git config --list
, чтобы показать все, которые Git найдёт:
$ git config --list user.name=Scott Chacon user.email=schacon@gmail.com color.status=auto color.branch=auto

Первоначальная настройка Git
Также вы можете проверить значение конкретного ключа, выполнив git config {ключ}
:
$ git config user.name
Scott Chacon

Первоначальная настройка Git
Как получить помощь?
Если вам нужна помощь при использовании Git'а, есть несколько способов открыть страницу руководства по любой команде Git'а:
$ git help <команда>
$ git help
Например, так можно открыть руководство по команде config:
$ git help config

Практиковать команды -
Как начать пользоваться командной строкой
Читать -
Pro Git book и практиковать.
Читать - githowto
Создать свой репозиторий и сделать первый git commit + git push и скинуть ссылку на репозиторий
Домашнее задание