Контроль версий. Наводим порядок с помощью Git

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

Мы тоже много лет назад начинали писать код и обслуживать проекты по простой схеме:

  1. подключаемся к серверу

  2. открываем нужный файл

  3. пишем код

  4. сохраняем изменения

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

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

А если проектов много? А если коллег много? Как навести порядок и сделать производственный процесс прозрачным? - Правильно, контроль версий.

На выбор есть несколько популярных инструментов: git, Mercurial и дедушка SVN.

Первый - безусловный лидер, вокруг него сформировано самое большое сообщество и, как следствие, самая развитая инфраструктура: GitHub, GitLab и интеграция, наверное, во всех современных инструментах и средах. Его используем мы и рассказывать будем о нём.


Что представляет из себя git?

Это распределенный реестр с набором инструментов.

Сейчас на слуху технология blockchain, так вот git в некотором роде и есть blockchain. Все транзакции учтены, система распределена и децентрализована, подмена транзакций исключена, всё контролируют хэши.

Проект под управлением git представляет из себя дерево, математический граф, от чего многие сущности в нем называются соответствующим образом: tree, branch




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

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


Как начать?

Начать очень просто, особенно если вы работает под Linux (в нашем случае Ubuntu).
В этом случае открываем терминал и просим систему установить из репозитория текущую стабильную версию git:


Для других систем перейдите в раздел загрузки на оф.сайте и проведите стандартную процедуру установки.

Теперь перейдем в директорию нашего проекта и инициируем новый репозиторий:


Всё, теперь всё содержимое этого раздела и все будущие изменения в нём будут отслеживаться контролем версий.

Мониторить текущую ситуацию с изменениями можно с помощью команды git status.
Создадим два новых файла и проверим видит ли система контроля изменения в рабочей директории:


Добавим файлы к коммиту командой git add:


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

Проверим историю коммитов командой git log:


Как видим, наш коммит прописался в реестр.
Теперь удалим один из файлов и запишем это в новый коммит:


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


Мы воспользовались более сложным вариантом git log для вывода емкой истории коммитов, командой git reset переключили состояние ветки, командой git status проверили состояние файлов на момент перед коммитом, с помощью git checkout из подсказки отменили внесенные изменения и системной командой ls убедились в том, что файл b.txt снова на месте.

Теперь создадим ветку, в которой будем вести параллельную разработку:


Мы проверили текущую ветку с помощью git branch, переключились на новую ветку с помощью git checkout, создали и закоммитили новый файл.
Переключимся обратно на master и убедимся, что никакого c.txt здесь нет.


Сведем обе ветки:



Как видим, c.txt и соответствующий коммит появились в ветке master.

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


Что дальше?

  1. Обучаете сотрудников навыкам работы с git

  2. Подключаете собственный репозиторий проектов (GitHub, GitLab, BitBucket или собственный)

  3. Формируете команды по рангам - тимлиды, джуниоры, сеньоры, тестировщики, devops'ы

  4. Настраиваете среды развертывания

  5. Интегрируете контроль версий с IDE

  6. Налаживаете производственные линии


Что мы получили, внедрив контроль версий?

  1. Рабочий процесс стал осязаемым и прозрачным

  2. Все изменения фиксируются, результат труда не теряется

  3. Возможность подключать к разработке множество сотрудников

  4. Прозрачность действий участников разработки

  5. Возможность быстро откатывать проект на нужное состояние

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

  7. Возможность работать со множеством проектов и масштабироваться

  8. Проведение code-review и предрелизного тестирования, допуская на продакшн только надежные и проверенные изменения

  9. Настроили автоматические схемы развертывания изменений

  10. Построили более эффективные производственные схемы



Алексей Андросов
Руководитель отдела веб-разработки