PreWorking 1.4: Системы контроля версии

P

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

1. Общая информация:

     1.1 ООП

     1.2 Принципы проектирования

     1.3 Паттерны — часть 1 — часть 2

     1.4 Системы контроля версии

     1.5 Использование third-party решений в iOS разработке

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

Системы контроля версии: Почему это важно?

Нет смысла читать долгие лекции о том, почему это важно. Стоит привести знакомые многим примеры. Вам же знакомо это?

  • Общались с командой по электронной почте об обновлениях
  • Хранили разные версии приложений где то на Dropbox или Google Drive
  • Случайно переписывали некоторые файлы
  • Теряли из за этого некоторые наработки и писали код заново

Забудьте все это и смотрите вперед! С системами контроля версий:

  • Имена файлов и структуры каталогов, которые соответствуют членам команды.
  • Внесение любых изменений без страха что то потерять.
  • Использовать систему контроля версий для обмена проектом с командой.
  • Наглядность: кто и когда и какие делал изменения.

Системы контроля версии: Основные понятия

Отслеживание изменений

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

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

Набор файлов или каталогов , которые находятся под контролем версий чаще называют репозиторием .

По мере внесения изменений, он будет отслеживать каждое изменение. Процесс будет прозрачным для вас, пока вы не будете готовы совершить (Commit) эти изменения.

Commiting

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

Rsvision и Changset

При коммите производятся изменения, отраженные в Revision с уникальной версией. Ревизии могут быть с нарастающим числом (1-2-3-4…) или с уникальным хеш (846eee7d92415cfd3f8a936d9ba5c3ad345831e5) в зависимости от системы. Зная номер ревизии, можно легко просматривать версии и ссылаться на них позже. Changset будет включать в себя ссылку на человека, сделавшего коммит, время коммита, затронутые файлы, комментарии, изменения.

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

Версии

Например, если вы создадите свой репозиторий на Github, то каждый пользователь сможет создавать свои версии вашего репозитория. Вы же сможете, не ломая вашу версию, просматривать все предложенные коммиты и их авторов.

Получение обновлений

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

Конфликты

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

Определение различий

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

Версии

Создание ветвей и слияние

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

После того, как вы чувствуете, что ваши экспериментальные изменения успешны, вы захотите сделать их частью мастера. Это и есть слияние. Поскольку система управления версиями записала каждое изменение, она знает , как был изменен каждый файл. Путем слияния ветви с мастера (или с другой ветвью), ваш инструмент управления версиями будет пытаться плавно объединить каждый файл и строку кода автоматически. После того, как ветка объединяется она обновляет мастер с последними файлами.

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

Системы контроля версии: Типы управления версиями

Существует две основные категории систем управления версиями, централизованные и децентрализованные (также известные как распределенные).

Централизованное управления версиями

Версии

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

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

Версии

Распределенные системы — более новый вариант. В распределенной системе управления версиями, каждый пользователь имеет свою собственную копию всего хранилища, а не только редактируемые файлы. Думайте об этом как о сети отдельных хранилищ. Именно такой системой является Git, который вы обязательно должны знать при устройстве на работу iOS-программистом. Лучш

Системы контроля версии: Полезные ссылки для углубления в тему

 

Поддержите ресурс blog.justDev:

Сведения об авторе

Игорь Малеваный

Добавить комментарий

Instagram

Поддержите ресурс blog.justDev:

Свежие записи

Рубрики