что такое система управления версиями
Что такое система контроля версий и как ей пользоваться
В арсенале веб-разработчика много полезных инструментов, которые позволяют автоматизировать решение разных задач. Без них время работы сильно увеличивается. А продуктивность падает, потому что приходится вручную делать то, что можно решить с помощью десктопных программ или браузерных расширений.
В статье поговорим о системе контроля версий. Разберёмся, зачем она нужна, как пользоваться инструментом и расскажем о популярных ошибках, которые допускают новички и опытные программисты.
Что такое система контроля версий
Система контроля версий — программное обеспечение, которое обеспечивает командную работу в рамках одного или нескольких проектов. Команда разработчиков взаимодействует с консольным или браузерным инструментом для выгрузки кода на сервер, скачивания его на рабочий компьютер и изменения структуры.
Новичкам обычно сложно вникнуть в технические подробности работы системы контроля версий, поэтому мы постараемся объяснить суть простым языком. Не старайтесь сразу погружаться в термины, пользы от этого будет мало.
Представьте, что играете в компьютерную игру. По мере прохождения миссий происходит сохранение контрольных точек. Даже если выключить компьютер и зайти в приложение через несколько дней или месяцев, прогресс не потеряется. В любой момент можно выбрать контрольную точку и пройти миссию заново.
Система контроля версий работает по аналогичной схеме. Она хранит все версии проекта и обеспечивает к ним доступ. Любой член команды может взаимодействовать с основной «веткой» проекта или создавать новые.
Самой популярной системой контроля версий является Git, поэтому мы не будем подробно останавливаться на альтернативных решениях и расскажем об этом инструменте.
Собрали основные понятия, которые будут полезны всем, кто захочет освоить работу в Git:
Система контроля версий — полезный инструмент, который нужен не только программистам, работающим в команде. Он пригодится и самостоятельным разработчикам для удобного хранения данных проекта. Если что-то пойдёт не так, в любой момент можно вернуться к контрольной точке и начать заново.
Зачем она нужна
Мы уже частично ответили на этот вопрос, но чтобы новички лучше поняли принцип работы, остановимся на нём ещё раз. Если представить работу над проектом в виде прохождения игры, то контрольные точки — промежуточные версии проекта.
Допустим, программист в одиночку работает над плагином для WordPress. Заказчик добавил в техническое задание обязательное условие — использование Git или аналогов. У него большие планы по разработке продукта, поэтому он хочет, чтобы данные находились в свободном доступе.
Программист создаёт репозиторий и начинает работать над плагином. В основной ветке у него хранится первая рабочая версия продукта. После каждого изменения разработчик добавляет новый коммит, а для внедрения масштабных изменений создаёт параллельные ветки.
Дело близится к релизу, но заказчик внезапно обнаруживает серьёзный баг, который нужно срочно исправить. Разработчик возвращается к контрольной точке (коммиту), в которой он допустил ошибку, исправляет её и обновляет основную ветку.
Теперь представьте, что разработка плагина велась на компьютере программиста. Он не использовал систему контроля версий и не хранил промежуточные копии плагина. Ему придётся либо переписывать проект почти с нуля, либо сильно постараться, чтобы исправить баг без изменения основной логики.
Если над сайтом, плагином или сервисом работает команда разработчиков, без системы контроля версий не обойтись. Каждый из них отделится от master-ветки и будет работать над своими задачами. После завершения работы, коллеги проведут кодревью и проект можно собрать воедино.
Git не только позволяет сохранять контрольные точки проекта, но и помогает устранять конфликты. Часто бывает так, что программисты одновременно работают над одной функцией и заливают изменения в репозиторий. В этом случае система обнаруживает конфликт и пытается исправить его автоматически.
Если Git не решит проблему самостоятельно, программисты увидят её и смогут устранить вручную. Окончательное решение всегда остаётся за разработчиком. Он контролирует процесс и решает, как будет происходить дальнейшая работа.
Какие задачи решает система контроля версий:
Git или другая система контроля версий также важна в работе программиста, как и сохранение бэкапов. В любой момент могут понадобиться исходники. И если их не будет, появятся дополнительные проблемы.
Как пользоваться системой контроля версий
Уже давно появился стереотип, что программисты очень любят работать с консолью. Новички представляют, что опытные разработчики вводят 20 команд в минуту и не используют веб-версии с user-friendly интерфейсами.
Git в стандартном варианте устанавливается на компьютер и представляет собой командную строку с минималистичным интерфейсом. Разработчики обычно разделяются на два лагеря: одни пользуются консольной версией, а вторые предпочитают вариант с графической оболочкой.
Если не хотите осваивать консоль и тратите много времени на ввод простых команд, лучше выбрать GitHub. Это крупнейший веб-сервис, на котором размещены тысячи проектов для совместной разработки. Платформа основана на системе контроля версий Git и обеспечивает удобную командную работу.
Любой пользователь может зарегистрироваться на сайте GitHub, чтобы создавать репозитории для своих проектов. Платформа отлично подходит для новичков и даёт полезный опыт. В системе много проектов с открытым исходным кодом, которые можно дорабатывать по своему усмотрению.
По данным GitHub в системе 56 млн разработчиков, больше 100 млн репозиториев и 3 млн организаций. Клиенты, которые обращаются к программистам за разработкой сайта, сервиса или приложения часто добавляют в список требований использование GitHub.
Git и GitHub не получится освоить за несколько часов, если раньше не было опыта работы с системами контроля версий. Новичкам не надо пытаться сразу выучить все термины. Лучше разобраться с основными понятиями, изучить несколько полезных статей и протестировать Git самостоятельно.
Популярные ошибки при работе с Git
Собрали распространённые ошибки, которые мешают начинающим разработчикам полностью использовать возможности системы контроля версий и создают дополнительные проблемы. Некоторые ошибки актуальны и для опытных программистов:
Система контроля версий — must have инструмент для разработчиков с разным опытом. Новичкам лучше сразу освоить его, чтобы использовать для своих проектов и получить дополнительное преимущество перед конкурентами, которые не знают Git или аналоги.
Введение в системы контроля версий
Часто разработчики трудятся в команде над одним проектом, а значит, сразу несколько человек могут изменять один файл одновременно. Чтобы избежать путаницы, в таких случаях используют систему контроля версий, которая позволяет хранить историю изменений проекта и при необходимости помогает вернуться к предыдущей версии.
Версионирование
Чтобы лучше понять проблему версионирования, рассмотрим пример дизайнера, который закончил работать над проектом и отправил финальную версию заказчику. У дизайнера есть папка, в которой хранится финальная версия проекта:
Этим всё не ограничилось, в итоге структура проекта разрослась и стала выглядеть так:
Вероятно, многие уже сталкивались с подобным, например, при написании курсовых работ во время учёбы. В профессиональной разработке создавать новые файлы для версионирования — плохая практика. Обычно у разработчиков в папке проекта хранится множество файлов. Также над одним проектом может работать несколько человек. Если каждый разработчик для версионирования будет создавать новый файл, немного изменяя название предыдущей версии, то в скором времени в проекте начнётся хаос и никто не будет понимать, какие файлы нужно открывать.
Для решения проблемы с сохранением новой версии файлов удобно использовать системы контроля версий. Одна из самых популярных — Git. Работу Git можно сравнить с процессом сохранения и загрузки в компьютерных играх:
Папка, содержащая данные игры, могла бы выглядеть так:
Файлы, необходимые для работы приложения, хранятся в рабочей области. В папке saves хранится история всех сохранений игры. Git сохраняет код вашего проекта по такому же принципу: сохранения попадают в специальную скрытую папку, а рабочей областью является содержимое корневой папки.
Основные понятия
Список терминов, которые будут вам полезны.
Репозиторий
Рабочая область и хранилище
Корневая папка проекта — это рабочая область. В ней находятся все файлы и папки, необходимые для его работы.
Коммит
В итоге проект работает так:
Система контроля версий Git
Git — это распределённая и децентрализованная система управления версиями файлов. Децентрализованная система означает, что у каждого разработчика есть личный репозиторий проекта с полным набором всех версий. А все необходимые для работы файлы находятся на компьютере. При этом постоянное подключение к сети не требуется, поэтому система работает быстро. При командной разработке нужна синхронизация репозиториев, так как проект — один и его состояние должно быть у всех одинаковым.
Работа в команде
Как синхронизовать данные репозиториев между разработчиками? Изначально Git репозитории сами могут синхронизироваться от пользователя к пользователю. Дополнительные программы для этого не нужны. Есть специальные команды в консоли, позволяющие передавать данные из одного репозитория в другой.
Репозитории можно синхронизировать между пользователями.
Этот способ сложный и редко используется. Чаще всего разработчики синхронизируют локальный репозиторий с удалённым. Удалённый репозиторий — это тот же репозиторий, только его данные находятся в облаке.
Синхронизация через удалённый репозиторий.
Этапы синхронизации
Как сделать так, чтобы разработчик смог передать актуальную версию проекта коллеге?
Синхронизация (push и pull) между локальными и удалённым репозиториями.
Типовой рабочий процесс с использованием Git
Коммиты B1 и B2.
Игорь запушил свои коммиты.
После пуша данные синхронизировались с удалённым репозиторием. Но как Алисе теперь получить изменения? Для этого она выполняет команду git pull и получает все изменения из облака к себе на компьютер. Таким образом, состояние проекта у Игоря и Алисы синхронизировались, и они могут дальше продолжить работать над ним.
Данные у обоих разработчиков синхронизировались.
Параллельные изменения
Два пуша в одно время?
Конфликт
Дело в том, что Игорь и Алиса изменили одинаковый файл и теперь Алисе предстоит решить конфликт.
Конфликт
Существуют два вида конфликтов:
Ниже рассмотрим оба варианта.
Слияние
Допустим, что на третьей строке Игорь добавил в проект шапку, а на четвёртой Алиса добавила футер.
Игорь сделал шапку и отправил коммит, а Алиса добавила подвал.
Git видит, что произведённые изменения не затрагивают друг друга. Он сам объединит две версии проектов в одну, совершив слияние. После этого Алиса спокойно синхронизируется с удалённым репозиторием, отправив новую версию проекта.
Изменения в проекте не пересекались и Git выполняет слияние сам.
Слияние.
Алиса и Игорь изменили один и тот же блок.
Версии файла.
Версии проектов разделяются строками второй, четвёртой и шестой. Их нужно удалить и оставить правильный вариант заголовка. После того как Алиса это сделает, она сможет закоммитить изменения и запушить их на удалённый репозиторий. Игорь же при следующей синхронизации с облаком получит тот вариант заголовка, который выбрала Алиса.
Окружение Git
Git — удобная система. Плюсом является то, что вокруг него создано множество сервисов, которые позволяют сделать работу с ним удобнее. Расскажем о тех, что будут вам полезны в начале работы.
GitHub
GitHub — это сайт, сервис и то самое облако, в котором можно хранить удалённые репозитории и через которое коллеги могут синхронизировать свои версии проектов. Как зарегистрироваться, мы рассказали в этой статье.
Пройдите бесплатные курсы по фронтенду и узнайте, как верстать сразу хорошо.
Нажатие на кнопку — согласие на обработку персональных данных
Введение в системы контроля версий — Основы Git
Рекомендуем перейти в курс Введение в Git
Мы обновили этот курс — добавили новые темы, самостоятельные задания и практические упражнения. Посмотрите этот урок по ссылке: https://ru.hexlet.io/courses/intro_to_git/lessons/intro/theory_unit
Основы VCS
Введение
Перед тем, как говорить про какую либо конкретную систему контроля версий необходимо понимать, что это такое, какими они бывают и зачем вообще они появились. Эта лекция предназначена для первоначального знакомства с системами контроля и управления версиями, и сначала я расскажу о происхождении инструментов для контроля версий, расскажу, какие системы управления версиями сейчас популярны и в чем у них основные различия.
О контроле версий
Что такое контроль версий, и зачем он вам нужен?
Наверное стоит начать с определения системы контроля версий (СКВ) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов.
В последнее время файлы являются конечным результатом для многих профессий (для примера, писательскую деятельность, научные работы и, конечно, разработку программного обеспечения). Тратится много времени и сил на разработку и поддержку этих файлов и никто не хочет, чтобы пришлось тратить еще больше времени и сил на восстановление данных потерянных в результате каких-либо изменений.
Представим, что программист разрабатывает проект состоящий из одного небольшого файла (кстати, пример вполне реальный, не синтетический, встречался в реальной жизни). После выпуска первой версии проекта перед ним встает непростой выбор: необходимо исправлять проблемы о которых сообщают пользователи первой версии и, в тоже время, разрабатывать что-то новое для второй. Даже если надо просто исправлять возникающие проблемы, то велика вероятность, что после какого-либо изменения проект перестает работать, и надо определить, что было изменено, чтобы было проще локализовать проблему. Также желательно вести какой-то журнал внесенных изменений и исправлений, чтобы не делать несколько раз одну и ту же работу.
В простейшем случае вышеприведенную проблему можно решить хранением нескольких копий файлов, например, один для исправления ошибок в первой версии проекта и второй для новых изменений. Так как изменения обычно не очень большие по сравнению с размером файла, то можно хранить только измененные строки используя утилиту diff и позже объединять их с помощью утилиты patch. Но что если проект состоит из нескольких тысяч файлов и над ним работает сотня человек? Если в этом случае использовать метод с хранением отдельных копий файлов (или даже только изменений) то проект застопорится очень быстро. В последующих лекциях, для примеров я буду использовать исходные коды программ, но на самом деле под версионный контроль можно поместить файлы практически любого типа.
Если вы графический или веб-дизайнер и хотели бы хранить каждую версию изображения или макета — а этого вам наверняка хочется — то пользоваться системой контроля версий будет очень мудрым решением. СКВ даёт возможность возвращать отдельные файлы к прежнему виду, возвращать к прежнему состоянию весь проект, просматривать происходящие со временем изменения, определять, кто последним вносил изменения во внезапно переставший работать модуль, кто и когда внёс в код какую-то ошибку, и многое другое. Вообще, если, пользуясь СКВ, вы всё испортите или потеряете файлы, всё можно будет легко восстановить. Вдобавок, накладные расходы за всё, что вы получаете, будут очень маленькими.
Локальные системы контроля версий
Одной из наиболее популярных СКВ такого типа является RCS (Revision Control System, Система контроля ревизий), которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. RCS была разработана в начале 1980-х годов Вальтером Тичи (Walter F. Tichy). Система позволяет хранить версии только одного файла, таким образом управлять несколькими файлами приходится вручную. Для каждого файла находящегося под контролем системы информация о версиях хранится в специальном файле с именем оригинального файла к которому в конце добавлены символы ‘,v’. Например для файла file.txt версии будут храниться в файле file.txt,v. Эта утилита основана на работе с наборами патчей между парами версий (патч — файл, описывающий различие между файлами). Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи. Для хранения версий система использует утилиту diff. Хотя RCS соответствует минимальным требованиям к системе контроля версий она имеет следующие основные недостатки, которые также послужили стимулом для создания следующей рассматриваемой системы:
Централизованные системы контроля версий
Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (ЦСКВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий.
Такой подход имеет множество преимуществ, особенно над локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте. Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё — всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей.
CVS (Concurrent Versions System, Система совместных версий) пока остается самой широко используемой системой, но быстро теряет свою популярность из-за недостатков которые я рассмотрю ниже. Дик Грун (Dick Grune) разработал CVS в середине 1980-х. Для хранения индивидуальных файлов CVS (также как и RCS) использует файлы в RCS формате, но позволяет управлять группами файлов расположенных в директориях. Также CVS использует клиент-сервер архитектуру в которой вся информация о версиях хранится на сервере. Использование клиент-сервер архитектуры позволяет использовать CVS даже географически распределенным командами пользователей где каждый пользователь имеет свой рабочий директорий с копией проекта. Как следует из названия пользователи могут использовать систему совместно.
Возможные конфликты при изменении одного и того же файла разрешаются тем, что система позволяет вносить изменения только в самую последнюю версию файла. Таким образом всегда рекомендуется перед заливкой своих изменений обновлять свою рабочую копию файлов на случай возможных конфликтующих изменений. При обновлении система вносит изменения в рабочую копию автоматически и только в случае конфликтующих изменений в одном из мест файла требуется ручное исправление места конфликта.
CVS также позволяет вести несколько линий разработки проекта с помощью ветвей (branches) разработки. Таким образом, как уже упоминалось выше, можно исправлять ошибки в первой версии проекта и параллельно разрабатывать новую функциональность.
CVS использовалась большим количеством проектов, но конечно не была лишена недостатков которые позднее привели к появлению следующей рассматриваемой системы. Рассмотрим основные недостатки:
Subversion
Subversion (SVN) был разработан в 2000 году по инициативе фирмы CollabNet. SVN изначально разрабатывался как «лучший CVS» и основной задачей разработчиков было исправление ошибок допущенных в дизайне CVS при сохранении похожего интерфейса. SVN также как и CVS использует клиент-сервер архитектуру. Из наиболее значительных изменений по сравнению с CVS можно отметить:
Распределённые системы контроля версий
И в этой ситуации в игру вступают распределённые системы контроля версий (РСКВ). В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий. Поэтому в случае, когда «умирает» сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных.
Кроме того, в большей части этих систем можно работать с несколькими удалёнными репозиториями, таким образом, можно одновременно работать по-разному с разными группами людей в рамках одного проекта. Так, в одном проекте можно одновременно вести несколько типов рабочих процессов, что невозможно в централизованных системах.
Зачем нужны распределенные системы?
Краткое описание популярных распределенных СУВ
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
Системы контроля версий — основа командной разработки
Системы контроля версий (их ещё называют системами управления версиями) – один из инструментов, который использует в своей работе любой программист от первокурсника до опытного тим-лида с сотнями успешных проектов.
— Ссылки на примеры кода в репозиториях помещают в своё портфолио.
— Большие проекты с открытым программным кодом получают тысячи улучшений, благодаря размещению на специализированном хостинге.
— От 30 до 70% кода, использованного в программном продукте, профессиональные разработчики могут скопировать с проектов, представленных в открытых репозиториях.
Незаменимы системы контроля версий в командной разработке, где синхронизация процесса играет важную роль.
Но даже если Вы принципиально не работаете в команде, система контроля версий может помочь Вам справиться со многими сложными ситуациями.
С необходимостью отката программы к предыдущей версии рано или поздно сталкивается любой программист.
В точке А программа отлично работает, а попытка расширить функционал, ввести дополнительные переменные, классы и пр. приводит в появлению ошибки.
Распознать ошибку удаётся не всегда. Поэтому многие программисты предпочитают «пройти перезагрузку» — откатиться к стабильной рабочей версии и переписать дополнения заново, построчно анализируя весь добавленный код.
Реализовать такую процедуру помогает использование системы контроля версий (СКВ), которое позволяет четко отследить историю разработки, найти стабильную версию и продолжить работу.
В системе контроля версий может содержаться, как программный код, так и любая другая информация (включая текстовые файлы, изображения и т.п.)
Как осуществляется контроль версий
Существует несколько моделей хранения данных:
Примитивная модель хранения версий
В примитивной модели актуальные копии проекта перезаписываются в отдельную директорию через определённый промежуток времени.
— возможность восстановления данных одной из записанных версий.
— сложности с поиском необходимой версии в обширной и плохо структурированной базе данных;
— возможность потери данных вследствие возникновения физических поломок оборудования;
— отсутствие возможности совместной разработки.
Локальные системы контроля версий
Локальные СКВ обычно хранят на компьютере список изменений, внесенных в файлы. Основываясь на этих данных, система контроля версий воссоздает нужную версию файла (актуальную на определенный момент времени).
Локальные системы контроля версий
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— высокая скорость выполнения восстановления (база данных четко структурирована, поэтому сложностей при поиске не возникает, сетевая задержка отсутствует, поскольку данные хранятся непосредственно на рабочем компьютере).
— возможность потери данных вследствие возникновения физических поломок оборудования;
— отсутствие возможности совместной разработки.
Централизованные системы контроля версий
Централизованные системы контроля версий предполагают сохранение версий проектов на общий сервер, с которого потом получают нужные версии клиенты.
Централизованные системы контроля версий
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— возможность ведения командной разработки проекта;
— отсутствие доступа к данным при сбое работы сервера;
— довольно низкая скорость работы (из-за возникновения сетевых задержек).
Децентрализованные системы контроля версий
В децентрализованных системах контроля версий при каждом копировании удалённого репозитория (расположенного на сервере) происходит полное копирование данных в локальный репозиторий (установленный на рабочем компьютере). Каждая копия содержит все данные, хранящиеся в удалённом репозитории. В случае, возникновения технической неисправности на стороне сервера, удаленный репозиторий можно перезаписать с любой сохраненной копии.
Децентрализованные системы контроля версий
— возможность восстановления данных из определенной версии (точно определяется по времени записи);
— возможность ведения командной разработки проекта;
— при сбое работы сервера система сохраняет данные в локальном репозитории, что позволяет эффективно вести процесс разработки, а после восстановления работы сервера, передать все изменения в удаленный репозиторий;
— при физической поломке сервера данные можно легко перенести в новый удалённый репозиторий с любого локального репозитория;
— высокая скорость работы (в ходе работы данные записываются и получаются из локального репозитория, поэтому сетевые задержки отсутствуют).
Современные системы контроля версий
Существует много систем контроля версий (Git, Darcs, Mercurial, Bazaar, Monotone и т.д), сходных по принципу работы и конечным задачам. Отличаются они друг от друга архитектурой, использованными решениями и удобством работы.
Самая популярная на сегодняшний день система контроля версий – Git.
Git
Умение работать с git’ом — обязательный навык для программиста любого профиля. Можно долго обсуждать преимущества и недостатки разных систем контроля версий, но большинство компаний используют git, поэтому уметь работать с git’ом нужно всем.
Git – распределённая система контроля версий. Что даёт ей все преимущества децентрализованной СКВ:
— высокую скорость проведения всех операций (за счет отсутствия сетевой задержки);
— идеальные условия для командной разработки;
— страховку от потери информации при возникновении проблем с центральным сервером.
Для контроля версий в git используются 2 репозитория: локальный и удаленный. Локальный репозиторий (полноценный репозиторий, а не ссылки или копии отдельных ветвей) находится на компьютере разработчика, а удаленный на удалённом сервере. Доступ к удаленному репозиторию обеспечивается благодаря гит-хостингу Github, Google Code, GitLab и т.д.
Как работает git
Взаимодействие с удаленным репозиторием происходит при наличии интернета и, по сути, представляет собой синхронизацию двух репозиториев.
Команда push копирует новые данные, содержащиеся в локальном репозитории, в удалённый репозиторий, а команда pull передает данные из удаленного репозитория в локальный.
Каждая версия документа, внесенные обновления и т.д записываются в локальный репозиторий.
Дерево проекта
В репозитории содержится «дерево» проекта, то есть все сохраненные версии файлов.
Дерево может быть прямым (в этом случае каждое последующее сохранение файлов производилось после предыдущего без возвращения к более ранним версиям) и разветвленным.
К появлению «веток» приводит работа с более ранними версиями и сохранение внесённых изменений.
На различных ветках дерева содержатся сохранения, основой которых был один исходный файл. В ходе работы в файлы на разных ветках были внесены разные изменения. В системе управления версиями можно работать со всеми ветками дерева проекта, пошагово, изменяя и дополняя содержащиеся в них данные. После проведения ряда изменений 2 ветки могут «срастись», в новой версии файла будут учтены все внесенные изменения.
Git-хостинг
Для комфортной работы с git нужно зарегистрироваться на любом git-хостинге. Их довольно много: Github, Sourceforge, Google Code, GitLab, Codebase и т.д.
Самый популярный на данный момент git-хостинг – это Github.
Популярность его обоснована простым интуитивно понятным интерфейсом, поддержкой проектов с открытым кодом (возможностью бесплатно размещать такие проекты на хостинге) и обширным функционалом.
Git-клиент
Для удобства работы с системой контроля версий git разработан целый ряд графических git-клиентов. Это программы, позволяющие эффективно работать с системой контроля версий, используя графический интерфейс.
Многие IDE предполагают возможность работы с git.
Работа с Git через IDE
Работа с системами контроля версий — важный навык, нужный каждому программисту.
Осваивайте git, и пусть ваши данные всегда будут под надежной защитой.