Source control

• [x] Source control basic
• [x] Branching/Merging strategies
• [ ] Integration
• [x] Git
• [x] TFS
• [x] Other source controls

Source control basic (Основы системы управления версиями)

Система управления версиями (vcs) осуществляется в системе где центральная часть программного обеспечения сервера реализует хранение и отслеживание версий файлов, а также управляет доступом к файлам.

Зачем?

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

Отличия:

Главное отличие между системами контроля версий в том, какие они: клиент-серверные или децентрализованные (p2p). Есть ли у них центральный репозиторий (сервер), откуда код берется и куда возвращается с внесенными изменениями. Или это копия в локальном хранилище, обновляемая посредством пиров (пользователей сети): более децентрализованная сеть, используемая для синхронизации, обмена патчами (наборами изменений) и для поддержки текущего кода.

Обычная vcs включает поставщика управления версиями и несколько клиентов управления версиями.

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

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

• Архивирование последовательных версий управляемых элементов (сохраняются данные, которые отличают одну версию управляемого элемента от другой, различия между версиями и т.д.). Становится возможным получать любую версию управляемого элемента / назначить любую версию элемента в качестве последней версии.

• Ведение для управляемых элементов подробных журналов истории и версий.

• Коллективная работа над проектами: контролируемые элементы могут использоваться в нескольких проектах.

• Автоматизация часто повторяемых операций по управлению версиями (определение интерфейса командной строки где поддерживаются ключевые функции управления версиями, его можно использовать в командных файлах для автоматизации регулярно выполняемых задачи по управлению версиями).

• Восстановление случайно удаленных элементов.

• Экономия дискового пространства как на клиенте, так и на сервере управления версиями (поддержка экономии дискового пространства на сервере).

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

Branching/Merging strategies

Сценарии

проблема: сломанные сборки;
решение: создать ветвь разработки с целью изоляции параллельных вариантов разработки.

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

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

> При использовании одного потока разработки / осуществлении инкрементного и непрерывного выпуска ветви следует создавать ветви, только если изменения часто приводят к сбоям и вносят неустойчивость в процесс разработки.

Типичные сценарии

Сценарий 1 - без ветвей.

Команда работает только из главного дерева исходного кода. Ветви не создаются, отсутствует необходимость в изоляции. Характерно для мелких и средних команд, не требующих изолирования групп, функций / выпусков.

Сценарий 2 - ветвь выпуска.

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

Сценарий 3 - ветвь сопровождения.

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

Сценарий 4 - ветвь функции.

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

Сценарий 5 - ветвь группы.

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

ВОПРОСЫ ВЕТВЛЕНИЯ

Необходимо руководствоваться следующими рекомендациями:

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

Вывод: Ветви создаются с целью предотвращения изменений выпускаемой версии, для обслуживания предыдущей версии продукта / для поддержки изолированной параллельной разработки.

Integration

?в проект:

Git (Git version control software)

Отличие / какую проблему решает:

Система была создана для управления разработкой ядра Linux и использует следующий подход: в основу Git закладывались концепции, призванные создать более быструю распределенную систему контроля версий, в противовес правилам и решениям, использованным в CVS.

ОС

Git работает быстрее всего на Linux OC так как писалась изначально под нее. Также работает на Unix-подобных системах (как MacOS), для работы на платформе Windows используется пакет mSysGit.

Детали:

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

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

• Значительное увеличение быстродействия
• Дешевые операции с ветками кода
• Полная история разработки доступная оффлайн
• Распределенная модель
• Автоматическое резервное копирование всего репозиторий (при потере репозитория, можно взять один из присутствующих на каждой рабочей станции)
• Автономный доступ к репозиторию (можно увидеть полную историю проекта, каждую проверку, не запуская VPN-соединение работать)

Недостатки:

• Высокий порог вхождения для тех, кто ранее использовал SVN
• Ограниченная поддержка Windows (по сравнению с Linux)

Часто встречаемые проблемы и решения: https://tproger.ru/translations/most-common-git-screwupsquestions-and-solutions/

TFS

Продукт корпорации Microsoft, представляющий собой комплексное решение, объединяющее в себе систему управления версиями, сбор данных, построение отчётов, отслеживание статусов и изменений по проекту и предназначенное для совместной работы над проектами по разработке программного обеспечения.

Git и TFS

TFS — это комплексное решение, включающее в себя систему отслеживание ошибок, систему учёта рабочего времени, решения для поддержки Scrum методологии, инструменты для проведения инспекции кода и собственно систему контроля версий.

TFS — это сервер, поддерживающий управление версиями как с помощью Git, так и с помощью собственной VCS — TFVC (Team Foundation Version Control).

Other source controls

Apache Subversion (SVN)

SVN создавалась как альтернатива CVS с целью исправить недостатки CVS и в то же время обеспечить высокую совместимость с ней.

SVN - бесплатная система контроля версий с открытым исходным кодом, распространяется под лицензией Apache.

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

Многие разработчики переключились на SVN, так как новая технология унаследовала лучшие возможности CVS и в то же время расширила их.

SVN создана для более крупных проектов с ветвлением кода и многими направлениями разработки.

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

• Система на основе CVS (Concurrent Versions System, «Система одновременных версий»)
• Допускает атомарные операции
• Операции с ветвлением кода менее затратны
• Широкий выбор плагинов IDE
• Не использует пиринговую модель (децентрализованная сеть)

Недостатки:

• Все еще сохраняются ошибки, связанные с переименованием файлов и директорий
• Неудовлетворительный набор команд для работы с репозиторием
• Сравнительно небольшая скорость

Mercurial

Mercurial была выпущена одновременно с Git, распределенная система контроля версий.

Mercurial создавалась в качестве альтернативы Git для разработки модулей ядра Linux.

Отличие:

• Mercurial отличается от других систем контроля версий тем, что главным образом она написана на Python (не С). Однако, некоторые части выполнены в качестве модулей-расширений на C.
• Система децентрализованная.
• Mercurial сохранила некоторые характеристики SVN, являясь при этом распределенной системой, поэтому порог вхождения у нее ниже для тех, кто уже знаком с SVN.
• Документация по Mercurial полная, что помогает быстрее освоиться с различиями.
• Один из существенных недостатков Mercurial заключается в том, что в отличии от Git в ней нельзя объединить две родительские ветки, так как Mercurial использует систему плагинов, а не поддержку скриптов.

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

• По сравнению с Git легче в освоении
• Подробная документация
• Распределенная модель системы контроля версий

Недостатки:

• Нет возможности слияния двух родительских веток
• Использование плагинов, а не скриптов
• Меньше возможностей для нестандартных решений

Отличия централизованной СУВ от децентрализованной на примере GIT от TFS

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

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