Дадим определение:

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

Чтобы сформировать у вас интуитивное понимание, приведу пример. Представьте себе, что вы разрабатываете голосового помощника для мобильных устройств. Ваше приложение уже выпущено в Play Market и в AppStore и пользуется успехом. Теперь вам захотелось добавить в него новую функцию: таймер. Вы пишите код, загружаете обновление в Play Market и AppStore, но внезапно вы узнаете от пользователей, что все сломалось. Теперь, чтобы исправить ошибку, вам нужно пересматривать весь код, чтобы вспомнить, что вы изменяли, и убирать это.

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

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

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

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

Существует три основных разновидности архитектур систем контроля версий: локальная, централизованная и распределенная. Рассмотрим их все.

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

Для решения этих проблем была придумана локальная система контроля версий. Схематически она представляет из себя следующее:

Из рисунка видно, что есть несколько версий одного и того же файла. А сам файл сейчас находится в состоянии третьей версии.

Одной из самых популярных локальных систем контроля версий на сегодняшний день (не считая Git) остается система RCS. Она работает по принципу сохранения изменений в ваших файлах. То есть она хранит не целую новую версию, а только указания к изменению первоначального файла. Например, "добавить к предыдущей версии строку import math". Таким образом, последовательно изменяя файл, система воссоздает любую из его версий.

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

Например, чтобы старший разработчик проверил ваш код на ошибки, перед тем, как дать вам разрешение на внесение изменений в рабочий файл. Для решения этой проблемы была придумана централизованная система контроля версий. Схематически она устроена так:

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

Такими системами были очень популярные в свое время CVS, Subversion и Perforce. Долгое время такой тип системы контроля версий считался стандартом. Такая система довольно удобна с точки зрения руководства компании. Она позволяет им следить, кто и чем занимается в текущий момент, позволяет настроить: кому какие файлы можно редактировать, а кому - нельзя.

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

Если будет поврежден жесткий диск сервера, на котором хранятся данные, то восстановить их не удастся (если только не были сделаны копии), и вся работа будет потеряна.

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

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

Распределенная система контроля версий решает все описанные выше проблемы. К этой группе систем относится Git, Mercurial, Bazaar и некоторые другие. На схеме распределенные системы контроля версий выглядят так:

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

Кроме того, почему сервер обязательно должен быть один? Правильный ответ: серверов может быть сколько угодно! Это открывает безграничные возможности для коллаборации разработчиков. Ведь это значит, что если вы делаете какое-нибудь открытое программное обеспечение и используете систему контроля версий, любой человек сможет скопировать данные с вашего сервера на свой, улучшить это ПО, не боясь ошибок (ведь можно откатиться к предыдущей версии), а затем (с вашего согласия) записать улучшенную версию на ваш сервер. И так с миллионами людей по всему миру.

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

Git был разработан командой Линуса Торвальдса в 2005 году, как open-source аналог уже существующим системам. Но разработка Git не была спонтанным решением. Дело в том, что с самого первого релиза в 1991 году разработка ядра Linux выполнялась по старинке: старая версия архивировалась, а новые патчи от разработчиков становились новой версией.

Но с ростом популярности рос и объем данных, поэтому в 2002 году было принято решение перевести ядро Linux на распределенную систему управления версиями BitKeeper от BitMover Inc. Однако между компаниями произошел разлад и BitMover Inc. отозвали лицензию на бесплатное использование своего ПО.

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

Основные требования к новой системе были следующими:

1. Скорость
2. Простота дизайна
3. Поддержка нелинейной разработки (тысячи параллельных веток)
4. Полная распределенность
5. Возможность эффективной работы с такими большими проектами, как ядро Linux (как по скорости, так и по размеру данных)

Разработка новой системы контроля версий началась 3 апреля 2005 года, а первая версия Git была готова к 7 апрелю того же года. Ядро Linux было переведено на Git 16 июня. 25 июня Линус отказался от должности главного разработчика, но несмотря на это, проект до сих пор поддерживается мировым сообществом под руководством Джунио Хамано.

Чтобы в полной мере понять, в чем заключаются все преимущества Git, надо уметь работать в Git. Ну а пока мы не умеем, просто пробежимся по основным возможностям этой системы. Не пугайтесь новых непонятных слов, все термины будут подробно описаны позднее. Сейчас наша задача понять, что Git - это самая крутая VCS на сегодняшний день.

Итак, Git обладает следующими преимуществами.

Отсюда вытекает два серьезных преимущества: все работает очень быстро, и вы получаете полный контроль над репозиторием:

1. Чтобы создать репозиторий нужна всего одна команда - git init.
2. Все файлы VCS хранятся только в одной папке .git. Никаких .svn в каждой директории.
3. Вам не нужен постоянный и бесперебойный интернет. Утром - скачали данные с сервера к себе на машину, днем - поработали у себя, вечером - залили данные обратно на север. Проще, чем заливать каждый файл после изменения.
4. В локальном репозитории вы можете создавать дополнительные ветки, тестировать что-то новое и делать все, что угодно. Никто не увидит этого, ведь репозиторий только ваш.

В Git можно делать что угодно с коммитами:

1. Удалить
2. Изменить
3. Поменять местами
4. Объединить несколько коммитов в один
5. Разделить один коммит на несколько
6. Перетаскивать коммиты между ветками

Ветки в Git - это настолько мощный и функциональный инструмент, что все выполняется в них. От маленьких задач до релиза.

1. Создать ветку, переключиться между ветками, слить ветки, удалить ветку - рутинные операции.
2. За исключением релизных, ветки живут 1-3 дня. Создали ветку, написали новую функцию, протестировали, убедились, что все работает, слили с основной и удалили.

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

1. Перед тем, как делать коммит, можно посмотреть и настроить, какие файлы в него попадут. Например, если вы хотите зафиксировать изменения только в одном файле из целого проекта - Git позволит вам это сделать.
2. Вы можете занести в коммит только часть изменения в файле. А остальные изменения откатить, или положить в другой коммит.
3. Просмотр истории коммитов и различий в файлах
4. Можно посмотреть, какие изменения были внесены в файл в разных коммитах.
5. Можно посмотреть историю коммитов всей ветки, чтобы проследить, как менялись файлы.

Stash - это очень удобная функция Git. Она позволяет заморозить текущие изменения и переключиться на другую ветку.

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

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

Очень удобно проводить ревью задачи, которая выполнена в отдельной ветке. Посмотреть различия коммитов, что-то исправить, прокомментировать, отправить обратно на доработку, а потом объединить отдельные коммиты и слить в основную ветку.

Гитхаб, битбакет и другие бесплатные удаленные репозитории очень удобны и часто используются для open-source проектов. Там делают форки этих проектов, обсуждают их и развивают.

Для того, чтобы работать с Git, вам нужно поставить его на компьютер. Менеджер установки Git предлагает множество настроек. Большинство из них нужно оставить так, как они есть, но не всегда. Существует множество руководств по установке Git, поэтому здесь мы затронем только важные моменты.

Официальная страница Git по установке на разные системы: https://git-scm.com/book/ru/v2/Введение-Установка-Git

В целом процесс установки Git на Windows довольно стандартный. Необходимо:

1. Скачать установщик с официального сайта Git
2. Запустить его
3. Выбрать подходящие опции из предлагаемых мастером установки

Остановимся на самых важных из настроек.

1. Выбор имени основной ветки
Обычно выбирают main или develop, но вы можете выбрать любое другое слово.
Советуем задать имя вручную, а не позволять Git самому решать. Потому что эта версия Git может называть основные ветки master, а следующее обновление будет называть их как-нибудь по-другому. Это вызовет путаницу. Но если вы сами зададите имя ветки, новая версия Git будет использовать его же.

2. Настройка запуска Git из консоли
Еще одна настройка, на которой стоит остановиться - разрешить Git запускаться из ПО других компаний. Это позволит вам запускать Git напрямую из консоли Windows или любых эмуляторов консолей.

Остальные настройки в принципе должны быть понятны. Более того, после завершения установки вы все еще сможете отредактировать значение того или иного параметра с помощью утилиты git config. О ней мы подробнее расскажем в следующем уроке, но пример использования вы можете найти в следующем пункте про установку Git на Linux.

1. Установка Git
В линукс установку удобнее производить через консоль. Чтобы установить Git в Debian-based систему (напр. Ubuntu) наберите команду:

Если у вас другая система, подробную информацию по установке вы найдете на официальном сайте Git.

2. Настройка Git
Чтобы настроить Git на линуксе, вам нужно отредактировать файл ~/.gitconfig. Сделать это можно напрямую через редактор или с помощью утилиты git config. Второй способ является более предпочтительным с точки зрения безопасности.

Список возможных команд утилиты git config:

Чтобы задать имя начальной ветки выполните следующую команду:

Более подробно про настройку можно почитать в официальном руководстве Git.

Также предлагаем вам посмотреть нашу видео-инструкцию к текущему уроку. В ней мы:

1. Устанавливаем Git
2. Настраиваем Git
3. Создаем репозиторий Git