17 587 
Оставить комментарий
Сохранить статью:
- Принцип работы системы контроля версий
- Задачи для системы контроля версий
- Типы систем контроля версий
- Обзор наиболее популярной системы контроля версий GIT
- Список терминов для работы с системой контроля версий GIT
- Ошибки при работе с GIT
-
Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.Бесплатно от Geekbrains
Система контроля версий – это обязательный инструмент в арсенале программиста любого уровня: от новичка, который только осваивается в профессии, до тимлида, чей опыт исчисляется многими годами и проектами.
И если профи хорошо представляют себе задачи и возможности такой системы, то начинающим необходимо дать некоторые объяснения. Впрочем, иногда и опытные программисты совершают ошибки при работе с системой.
В нашей статье мы расскажем, зачем нужен данный инструмент, как им правильно пользоваться и разберем некоторые ошибки, которые допускают чаще всего.
Принцип работы системы контроля версий
Пожалуй, многие представляют себе, каким образом вносятся изменения в тот или иной проект в процессе работы. То есть, тут стоит задача не потерять существующую работоспособную версию проекта. Для этого обычно создается новая папка (чаще всего ее так и называют «Новая папка», дополняя имя, к примеру, датой или парой символов), в которую вы копируете имеющуюся версию и все дальнейшие изменения производите уже именно с ней.
Подобных папок может набраться довольно много. Из-за этого в какой-то момент усложняется откат к предыдущим версиям, труднее становится контролировать и упорядочивать вносимые изменения и т.д. А если проект ведут несколько специалистов, картина усугубляется.
Системы контроля версий (СКВ или VCS) разработаны специально для того, чтобы максимально упростить и упорядочить работу над проектом (вне зависимости от того, сколько человек в этом участвуют). СКВ дает возможность видеть, кто, когда и какие изменения вносил; позволяет формировать новые ветви проекта, объединять уже имеющиеся; настраивать контроль доступа к проекту; осуществлять откат до предыдущих версий.
Задачи для системы контроля версий
В целом задачи для системы контроля версий уже описаны выше, но можно пояснить еще, для тех, кто сталкивается с термином впервые. Для наглядности представьте, что работа над проектом – это игра, которую нужно пройти, двигаясь от одной контрольной точки – к другой (это и будут промежуточные версии проекта).
входят в ТОП-30 с доходом
от 210 000 ₽/мес
Скачивайте и используйте уже сегодня:
Топ-30 самых востребованных и высокооплачиваемых профессий 2023
Поможет разобраться в актуальной ситуации на рынке труда
Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка
Только проверенные нейросети с доступом из России и свободным использованием
ТОП-100 площадок для поиска работы от GeekBrains
Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽
Пусть, к примеру, разработку плагина для WordPress ведет один специалист. Заказчик вносит в ТУ требование обязательно использовать Git либо аналоги. Для него в будущем важно наличие свободного доступа к данным.
Например, в процессе работы заказчик замечает баг, который непременно должен быть устранен. Для этого разработчику достаточно вернуться к нужному коммиту и исправить в нем ошибку. После этого остается лишь обновить основную ветку.
Но чего можно ожидать, если программист на своем компьютере не использовал систему контроля версий и не сохранял создаваемые промежуточные копии плагина? Специалист будет переделывать проект практически заново. Возможно, ему и удастся внести нужные изменения, не нарушив основную логику, но это будет очень и очень сложно.
А теперь представьте, что работу над плагином ведут несколько человек. Тогда применение СКВ даже не обсуждается. Это позволит каждому разработчику, отделившись от основной ветки, выполнять свой конкретный круг задач. После чего специалисты проверят код на ошибки и объединят вместе все части проекта.
Если система не справится с проблемой, то разработчики получат информацию об этом и вручную всё «подчистят». В конечном счете, именно программист контролирует и процесс, и окончательный результат.
Вот перечень задач, выполняемых системой контроля версий файлов:
- Сохранение исходного кода. Информация сваливается на удаленный сервер и в репозитории остаются даже файлы, удаленные с компьютера разработчика.
- Возможность привлекать группу программистов, не покупая отдельно специальные инструменты для командной работы. Каждый свою задачу на персональном компьютере, обновляя файлы, когда это нужно.
- Отмена внесенных изменений. Всегда есть возможность вернуться к контрольной точке, провести ревью исходного кода и текущего, а затем обновить основную ветку.
- Распределенная работа над проектом. То есть, программисты могут создавать видоизмененный плагин, пока основная его версия спокойно функционирует на сайте.
Для программистов СКВ – вещь необходимая, в их работе без сохранения бэкапов просто не обойтись. На практике всегда в какой-то момент приходится возвращаться к исходникам, и если такой возможности не будет, то проблем не избежать.
Типы систем контроля версий
Локальные СКВ
Среди первых систем подобного плана была RCS, разработанная в 1985 году и сразу ставшая популярной.
Данная система контроля версий хранит и все зарегистрированные в ней файлы, и любые вносимые в них изменения. Специально к текстовым файлам применяется алгоритм дельта-компрессии. Это означает, что система сохраняет последнюю версию и все предшествующие ей изменения.
СКВ подобного плана решали лишь проблему хранения больших объемов данных.
Современные СКВ условно бывают двух видов, а именно, централизованные и распределенные системы контроля версий.
на курсы от GeekBrains до 12 мая
Централизованные СКВ
Далее предстояло решить проблему привлечения к работе над одним проектом нескольких специалистов (за разными компьютерами). Для этого и были разработаны централизованные системы контроля версий, такие как, к примеру, CVS, Subversion, Perforce. Они имеют собственный центральный сервер, где накапливаются все файлы проекта. Система контролирует и их сохранность, и выдачу их копий определенному ряду пользователей. Именно по такой схеме много лет и работали СКВ.
В целом подход хороший. Он позволяет администраторам достаточно просто отслеживать действия каждого привлеченного разработчика. Если сравнивать с локальными базами по каждому клиенту, то там осуществлять контроль куда сложнее.
Впрочем, и минусы тут, несомненно, есть. Главный из них – уязвимость централизованного сервера. Временное выключение сервера (пусть даже на час) останавливает работу программистов, они не могут ни сохранять новые варианты версий, ни взаимодействовать между собой. В случае же повреждения диска, на котором хранится центральная база данных, все наработки по проекту теряются безвозвратно.
Единственное, что у вас может сохраниться – это крохи информации, оставшейся на рабочих машинах программистов. Кстати, с локальными системами контроля версий та же история: если все данные по проекту «лежат» в одном месте, вы можете лишиться их сразу в один момент.
Распределенные СКВ
И вот тут незаменимыми становятся распределенные системы контроля версий. Это, к примеру, Git, Mercurial, Bazaar, Darcs. Суть их работы состоит в выгрузке клиентам не только версий файлов с последними изменениями, а всего репозитория. Репозиторий (на сленге – «репа») – это место хранения и поддержания данных. Более того, условно говоря, различают центральный и локальные репозитории.
Потому что как только клиент скачивает измененную версию файлов, к нему в компьютер копируются все данные репозитория в полном объеме.
ТОП-100 площадок для поиска работы от GeekBrains
20 профессий 2023 года, с доходом от 150 000 рублей
Чек-лист «Как успешно пройти собеседование»
Еще один плюс подобных систем в том, что в большинстве из них доступно для хранения данных сразу нескольких удаленных репозиториев.
Сегодня практически стандартом по умолчание стало использование распределенной системы контроля версий GIT. Впрочем, популярные в прошлом варианты вроде Subversion тоже можно еще встретить в старых масштабных проектах.
Обзор наиболее популярной системы контроля версий GIT
Современный программист вне зависимости от его профиля должен знать, как работать с GIT. Да, у разных СКВ есть свои достоинства и недостатки, но большая часть компаний на сегодняшний день используют именно систему контроля версий GIT.
GIT относится к распределенным системам контроля версий, и как децентрализованная СКВ имеет свои преимущества:
- сетевых задержек не бывает, поэтому все операции выполняются очень быстро;
- идеально подходит для проектов, к работе над которыми привлекается целая команда специалистов;
- возможность сохранить данные в случае выхода из строя центрального сервера.
Версии хранятся тут в двух репозиториях, локальном (расположен на компьютере разработчика, причем именно репозиторий с полным объемом данных, а не ссылки на отдельные версии проекта) и удаленном (лежит на удаленном сервере). Получение данных с удаленного репозитория идет через гит-хостинги Github, Google Code, GitLab и прочее.
Достаточно лишь иметь интернет соединение, чтобы получать доступ к удаленному репозиторию. Взаимодействие просто представляет собой синхронизацию локального и удаленного репозиториев.
Любые изменения в документе и его новые версии сохраняются в локальном репозитории.
Набор всех сохраненных версий называют «деревом» проекта, и оно находится в репозитории.
Бывает прямое дерево, когда сохранения файлов выполняются последовательно, одно за другим без возврата к предыдущим вариантам.
Есть еще разветвленное дерево. Оно получается, если приходится дорабатывать старые версии, вносить в них изменения и потом сохранять.
Любые сохранения, получившиеся на ветках дерева, изначально наращиваются на один файл, называемый исходным. В процессе работы в него вносятся изменения. Система управления версиями позволяет одновременно корректировать, дополнять любую из веток дерева. В итоге некоторые из них «срастаются». Все изменения обязательно каждый раз сохраняются в последней версии файла.
Для настройки и последующей работы с системой контроля версий GIT понадобится регистрация на каком-либо из git-хостингов, к примеру на Github, Sourceforge, Google Code, GitLab, Codebase или на других.
Наибольшей популярностью из названых пользуется Github.
Почему именно он? Благодаря удобному интерфейсу, открытому коду (то есть, платить за размещение проекта на хостинге не нужно). Плюс у Github довольно широкие функциональные возможности.
В распоряжении пользователя тут целый набор графических git-клиентов, то есть специальных программ, позволяющих задействовать графический интерфейс для работы над проектом.
Существует много IDE, допускающих использование GIT.
Список терминов для работы с системой контроля версий GIT
Git (Гит) – система контроля версий файлов.
GitHub (Гитхаб) – специальный сервис, на котором хранятся репозитории. Именно через него идет работа над проектами.
Репозиторий GIT – файловый каталог, то есть, место, где лежат: файлы конфигураций; файлы с журналами проведенных в репозитории операций; индекс расположения файлов; и, собственно, само хранилище контролируемых файлов.
Локальный репозиторий – размещается в компьютере разработчика в каталоге. Все изменения проводятся и сохраняются сначала здесь, а потом уже пересылаются на удаленный репозиторий.
Удаленный репозиторий – тот, что размещен на удаленном сервере. Тут собираются все изменения, внесенные в проект, и здесь же их можно взять при необходимости.
Fork (Форк) – это копия репозитория, которая, по сути, представляет собой внешнюю ветку текущего репозитория. Такую копию может создать на Гитхабе любой пользователь, поработать с ней и через пулреквест прислать на ваш репозиторий измененный вариант.
Обновиться из апстрима – это когда своя локальная версия форка обновляется до последней сохраненной в репозитории версии (с которой и создавался форк).
Обновиться из ориджина – это когда версия локального репозитория обновляется до версии соответствующего ему удаленного репозитория.
Clone (Клонирование) – создание отдельного каталога, в который скачивается репозиторий с удаленного сервера. Далее этот каталог используется в работе в качестве репозитория.
Branch (Ветка) – параллельное «ответвление» в репозитории. С этой составляющей можно отдельно работать, не «задевая» при этом главную версию (с которой ветку можно вновь объединить, после проведения необходимых изменений).
Master (Мастер) – основная ветка репозитория, называемая еще главной.
Commit (Коммит) – сохранение изменений в репозиторий. Выполняется разработчиком на своем локальном компьютере.
Pull (Пул) – прием последних сохраненных изменений с удаленного репозитория.
Push (Пуш) – отправка свежих коммитов на удаленный репозиторий.
Pull Request (Пулреквест) – запрос на объединение основного репозитория с его форком. Вы, как владелец репозитория, решаете, удовлетворить этот запрос, или отклонить его.
Merge (Мёрдж) – слияние изменений, произведенных в разных ветках одного репозитория. На практике чаще происходит слияние основного репозитория с изменениями, произведенными в его ветке.
Кодревью – проверка кода (по внешнему виду, способности решать поставленные задачи, по соответствию иным требованиям).
Ошибки при работе с GIT
Тут собраны ошибки, из-за которых у начинающих программистов могут возникнуть трудности при работе с системами контроля версий. Впрочем, даже опытные разработчики эти ошибки тоже допускают:
- Нежелание использовать GIT. Такое случается, когда после запуска консоли программист не может в ней разобраться. Тогда можно вообще не оперировать с консолью, взяв для работы GitHub вместо десктопной версии.
- Невнимательное изучение официальной справки. А между тем, в ней много ценных сведений, помогающих существенно упростить процесс взаимодействия с репозитариями.
- Несоблюдение правил работы с GIT. Нарушение системных требований может стать причиной потери всех результатов работы над проектом. К примеру, в основную ветку нельзя вливать изменения, не прошедшие проверку.
- Ошибочное использование команд системы контроля версий. Запускайте команду лишь в том случае, когда точно знаете, какая операция при этом будет выполнена.
- Некорректные комментарии к коммитам. Практический совет: проработав несколько часов над кодом, не спешите сразу перебрасывать файлы на сервер. Составьте комментарии к ним чуть позже, на «свежую голову», чтобы не наделать ошибок и не ввести в заблуждение коллег, которые будут работать с файлами после вас.
- Выгрузка лишних файлов. То, что не нужно для проекта, легко удаляется либо исключается из структуры.
Как для опытных, так и для начинающих разработчиков, система контроля версий – ценный, незаменимый инструмент. Поэтому обязательно нужно научиться с ним работать, особенно новичкам. Это стопроцентно позволит оставить позади конкурентов, еще не знакомых с GIT или аналогичными системами.
Разберем 11 самых важных жизненных вопросов
Только до 
Эксклюзивные лекции по основам программирования
