Что такое Git и для чего он нужен

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

• Какие задачи решает контроль версий
• Как работает контроль версий
• Какие бывают системы контроля версий
• Первое поколение
• Второе поколение
• Третье поколение
• Заключение
• Дополнительные ссылки

Какие задачи решает контроль версий

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

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

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

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

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

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

К счастью, эту задачу решили ещё в 80-х годах. С тех пор инструментарий сильно развился и стал использоваться повсеместно не только для кода, но и, например, для написания и перевода книг. Решением является контроль версий. Выполняется он с помощью специальных программ, которые умеют отслеживать изменения кода. Вот некоторые из многочисленных возможностей данных систем:

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

В этом руководстве мы разберём общие принципы работы подобных программ.

Как работает контроль версий

Системы контроля версий (СКВ или VCS — Version Control System) часто встроены в инструменты, привычные даже далёким от программирования людям. Именно с них мы и начнём своё знакомство, а заодно погрузимся в соответствующую терминологию.

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

На картинке выше текущая версия файла обозначена как current. Всё остальное — это предыдущие версии текущего файла. Как видно, Dropbox позволяет восстановить любую версию файла.

Обратите внимание на эту фразу:

Dropbox keeps a snapshot every time you save a file. (Дропбокс сохраняет снимок каждый раз, когда вы сохраняете файл)

Снимок (snapshot; разг. снепшот) — очень важное понятие, которое будет встречаться нам в будущем. Его ещё называют снимком состояния или даже мгновенным снимком (буквальный перевод), но для простоты будем называть его просто «снимок».

В данном случае, снимок — это сам файл после изменения. И чтобы лучше понять этот термин, посмотрим на альтернативу — дельту изменения (diff). Представьте, что вместо сохранения новой версии файла Dropbox бы вычислял разницу между новым и старым файлом (а это не сложно сделать для текстовых файлов) и сохранял только её. Зачем так делать, спросите вы? Такой подход позволяет сэкономить место на диске, хотя и вносит дополнительную сложность при работе с файлами.

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

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

Сервис Google Docs автоматически делает снимки после каждого автосохранения (примерно раз в 5 секунд). Если документ за это время не изменился, то, естественно, новая версия не появляется. Множество таких версий образуют историю изменений.

На картинке выше история версий называется «Revision history». Ревизия — базовое понятие систем контроля версий. Любое зафиксированное изменение в системе контроля версий называется ревизией.

Обратите внимание на то, что ревизия и снимок — это не одно и то же. Фиксация изменений создаёт ревизию, но сама ревизия может содержать внутри себя либо дельту изменений, либо снимок.

Кстати, процесс переключения между ревизиями также имеет своё название. Когда мы загружаем конкретную ревизию, то говорят, что переключаемся на неё (checkout).

Между ревизиями можно выявлять различия в случае, если СКВ использует снимки, что демонстрирует нам Microsoft Word на картинке выше. Эту функциональность невозможно переоценить,поскольку посмотреть «а что же изменилось» требуется постоянно не только при работе с кодом. Приведу пример из собственной практики: согласование разных юридических документов (договоров) происходит сквозь череду правок. После того, как юристы поправили договор, хочется увидеть, а что же там изменилось.

Более того, в системах Linux есть команда diff, с помощью которой можно выяснить различия между любыми файлами даже без использования СКВ. Эти изменения можно сохранить в файл, а затем, используя программу patch, применить к исходному файлу.

diff index.js index2.js > index.patch

1c1

< const a = 5;

---

> const a = 8;

3a4

> console.log(a - b);

patch index.js -i index.patch -o index2.js

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

• Сохранение.
• Автосохранение.
• По кнопке (команде).

Последнее используется уже при работе с кодом.

Какие бывают системы контроля версий

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

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

В СКВ для кода процесс создания ревизии называется фиксацией (commit; разг. коммит). На работе вы будете часто слышать фразу «закоммитишь?» или «я закоммитил». Более того, обычно, вместо слова «ревизия» употребляют слово «коммит». И мы тоже так будем делать.

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

• Хорошее описание. Как правило, оно начинается кратким однострочным заголовком не более 50 символов, после которого, через пустую строку, следует более детальный поясняющий текст, если он требуется. Обратите внимание, что хорошим тоном является использование повелительного наклонения в заголовке: «Fix scrolling» (Исправить прокрутку), а не «Fixed scrolling» (Исправлена прокрутка) или «Fixes scrolling» (Исправляет прокрутку).
• Атомарность. Коммит должен решать одну задачу и желательно от начала до конца. Это позволит построить такую историю проекта, которую легко читать и понимать. А в случае необходимости можно легко откатить изменение или перенести его в другую версию программы.

Кроме этих базовых, существует и множество других рекомендаций входящих в понятие «хороший коммит».

Какие бы вы не использовали СКВ, базовый рабочий процесс один. Выглядит он так:

1. Инициализация (создание) репозитория.
2. Добавление новых файлов.
3. Коммит.
4. Любые операции с файлами (добавление, удаление или изменение).
5. Коммит.
6. ...

Под репозиторием понимается набор файлов и директорий, которые находятся под контролем версий.

СКВ принято делить на поколения, каждое из которых сильно изменяло подходы к работе.

Первое поколение

RCS, SCCS

• Работали с каждым файлом индивидуально.
• Только локальная работа.

Второе поколение

CVS, SourceSafe, Subversion

• Многофайловые.
• Централизованные.
• Требуют наличия сервера.

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

Третье поколение

Git, Bazaar, Mercurial

• Распределённые.
• У каждого участника свой полноценный локальный репозиторий.

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

Заключение

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

Дополнительные ссылки

• Введение в Git