Контроль версий — мегаполезная вещь, когда речь идёт о программировании в команде. Git – одна из таких систем, которая позволяет это сделать. Сегодня сказ о том, что такое Git и как им пользоваться.
👉 Важное пояснение про сторителлинг
Перед тем как рассказать про Git, нам нужно пояснить, что вообще такое системы контроля версий и зачем они нужны. Чтобы было проще, мы вынесли всё это в отдельный раздел — он ниже. Если его пропустить (хотя там и есть сторителлинг), дальше будет не очень понятно, а мы хотим, чтобы было понятно.
Как говорится, усаживайтесь поудобнее.
ИТ-сторителлинг про системы контроля версий
Допустим, у нас есть программист Вася, который пишет весь код у себя на компьютере. Вася — продвинутый программист, поэтому перед каждым большим изменением делает полную резервную копию всего кода. Так он не боится что-то поломать: всегда можно откатиться на предыдущую версию. Резервные копии он хранит на отдельной флешке. Если сгорит компьютер, флешка останется.
Скоро Вася понимает, что следить за изменениями в коде сложно: он не помнит, что менялось от версии к версии. Вася записывает изменения в блокнот, но это скоро перестаёт работать: блокнот не видит конкретные куски программы и не может показать, в каких конкретно местах что поменялось.
Через пару месяцев с блокнотом Вася понимает: надо что-то менять. Он идёт в интернет и читает статью про системы контроля версий (СКВ или VCS, от слов version control system).
👉 Системы контроля версий — это штуки, которые помогают разработчикам ориентироваться в коде, находить и отслеживать изменения. СКВ могут вернуть нужные файлы в исходное состояние или показать вам только те изменения, которые вы сделали за определённое время.
Примерный сценарий: в прошлую пятницу Вася напился и ночью кодил пьяным. Утром в субботу пришли его друзья, он показал им свой код, и один из тимлидов сел переписывать его систему запросов к базе данных. Потом в воскресенье у Васи было свидание с девушкой, и она показала ему, что можно использовать другой обработчик ошибок.
В понедельник Вася понял, что не всё из того, что произошло на выходных, должно остаться в итоговом коде. Он открывает СКВ и видит все изменения, разложенные по времени, с подсветкой:
«Ага, тут я кодил пьяным. Вот место, которое я переписал. Нормально. Надо только поменять названия переменных».
«Это мои друзья кодили. Сносим всё, чёртовы пижоны».
«А новый обработчик ошибок хорош. Возьму этот код в другие проекты».
СКВ прямо показывает: «Тогда-то было сделано такое-то изменение, вот, посмотри».
Теперь, когда мы всё это знаем, возвращаемся в обычный режим статьи.
Что такое Git
Git (он же Гит) — это одна из систем контроля версий, самая популярная на сегодня. Её придумал в 2005 году Линус Торвальдс, разработчик ядра Linux, чтобы вместе с товарищами работать над новой операционной системой.
Основное преимущество Гита — скорость работы, простота и работа с большими проектами. В отличие от других систем контроля версий, Гит не записывает изменения к каждому файлу, а как бы фотографирует весь проект целиком.
Главная особенность в том, что Гит помнит всё, что вы в него внесли, и может показать, какие именно строчки вы правили несколько лет назад, когда чинили ошибку авторизации, например.
На базе Гит есть сервис Гитхаб. Работает так:
- все рабочие файлы проекта синхронизируются между облаком и вашим компьютером;
- такая синхронизация происходит у каждого участника проекта;
- можно настроить автоматическую синхронизацию, а можно отправлять изменения вручную;
- можно отправить на сервер изменения, которые сделали вы на своём компьютере, а можно, наоборот, скачать себе те, которые внесли в проект другие программисты.
Это полезно, например, когда несколько человек параллельно пилят совместный проект. Каждый работает над своим файлом или даже своим куском одного файла. Всю работу авторы синхронизируют между собой, чтобы не было ситуации, что два человека редактируют один и тот же файл, а потом затирают результаты работы друг друга, сами того не зная.
Что такое Git-репозиторий (git repository)
Git-репозиторий — это хранение вашего проекта на сервере (например, на сервере GitHub, но можно и на любом другом облачном хранилище или вообще на домашнем компьютере).
Каждый программист может создавать сколько угодно репозиториев, по одному на каждый проект. А может вести все проекты в одном репозитории, но тогда это превратится в мешанину. Но каждый имеет право на мешанину.
В репозитории могут храниться:
- файлы с исходным кодом проекта;
- базы данных;
- картинки и графики;
- текстовые файлы;
- и всё остальное, что нужно проекту для работы.
Проще говоря, можно представить, что репозиторий, это папка, где лежат все файлы по проекту.
Ещё сразу дадим пару остальных терминов, которые будем часто использовать в статье.
Коммит
Коммит — это снимок проекта, который сохраняется в репозитории. Его можно сделать в любой момент, когда что-то мы изменили: создали первый файл в репозитории, изменили строку в коде, поменяли настройки для отслеживания файлов.
Программировать только в облаке неудобно — проще скачать себе на компьютер весь проект и писать код на своей машине. Но чтобы правки увидели остальные, их нужно отправить обратно в репозиторий. Это и есть коммит.
Коммитить можно и один файл, и сразу несколько. Система сама найдёт, что изменилось в каждом файле, и добавит эти изменения в проект. Но все эти правки внесутся в репозиторий за один раз, потому что при коммите обрабатываются сразу все добавленные в список файлы.
👉 Короче, коммит — это список изменений, которые нужно внести в текущую ветку проекта за один раз. Если изменений несколько, они применятся все и сразу. Нельзя из коммита взять одно изменение и применить его, а остальные не трогать.
Ветка
Несколько коммитов, объединённых в одну цепочку называют веткой (оно же — branch, или бранч). Иногда проект может развиваться по нескольким разным направлениям. Например, когда два разработчика начали писать каждый свою версию кода, у каждого эта версия будет включать свои коммиты. В конце можно будет сравнить работу обеих веток и оставить лучшую.
Так эти вещи могут выглядеть в системе контроля версий (1 — репозиторий, 2 — коммит, 3 — ветка):
Как реализованы системы контроля версий
Сейчас есть три принципиальные модели реализации СКВ: локальная, централизованная и распределённая.
Самая простая реализация СКВ — локальная. Это значит, что все изменения и резервные копии хранятся у вас на компьютере в специальной базе данных. Вы не зависите от интернета, полностью контролируете код и можете разрабатывать секретные вещи.
СКВ посложнее — централизованная. Их придумали, чтобы несколько программистов могли работать над одним проектом, не мешая друг другу. Такая система контроля версий состоит из сервера, на котором находится репозиторий, и рабочих станций, которые подключаются к серверу для работы над файлами.
Когда над одним файлом или модулем работают несколько программистов, сервер смотрит, какие изменения вносит каждый программист, и, если они делают разные вещи в одном и том же месте, — выдаёт сообщение или блокирует работу одного из них. Типа: «Вы исправляете один и тот же кусок кода, окститесь».
Можно сделать так, что каждый скачивает себе рабочую копию всего репозитория, работает в нём, а в конце дня отправляет его обратно на сервер. Сервер смотрит, можно ли объединить эти файлы без ошибок, и если нет — показывает конфликтные места, где два программиста написали в одном месте разный код.
С такой организацией уже можно работать командой над одним проектом, но в ней есть одно слабое место — сервер. Если он выйдет из строя, команда потеряет проект.
Распределённые СКВ решают эти проблемы так: каждый разработчик получает не просто несколько нужных для работы файлов, а весь репозиторий целиком. Если сервер выйдет из строя, он просто возьмёт полный репозиторий у любого программиста и скачает его себе. Точно так же и с остальными членами команды: если что-то пошло не так, всегда можно взять актуальные файлы у других и пользоваться ими.
Совместная работа тоже стала проще: все программисты работают над своим кодом, а потом отправляют изменения на сервер. Но они не попадают сразу в репозиторий, а ждут одобрения главного разработчика или ответственного за продукт. Если он одобряет запрос на добавление кода — этот код становится частью репозитория и сразу доступен для скачивания другими участниками. Таких запросов на добавление может быть много, поэтому нужно постоянно проверять, что же именно делает новый код и нужно ли его добавлять в проект.
👉 Git — это распределённая СКВ.
Принципы работы с Git
Работа с Git похожа на сохранения в играх или работу над графическим дизайном. Так всегда можно будет вернуться к одной из старых версий в случае поломки и посмотреть, как менялся проект на разных стадиях.
Вот несколько принципов работы с системами контроля версий, которые приняты среди разработчиков.
- Сохранять изменения нужно регулярно после всех серьёзных дополнений. Но слишком часто создавать изменения тоже не стоит. Сейчас объясним почему.
- Каждое изменение должно сопровождаться понятным описанием, чтобы разработчик и его коллеги понимали, что было сделано. Но если позволять себе и коллегам хранить в репозиториях записи о каждой созданной переменной, получится беспорядок и нагромождение логов. Описывать добавление новой сложной функции, класса или модуля — нормально, а новой переменной для цикла — ненормально.
- Надо создавать новые ветки, чтобы не писать всё в основной. Всегда есть как минимум одна основная ветка, которая отвечает за весь проект. Разработчик может создать другую тестовую ветку и проверить там новые модули кода. Потом, если ответственный за проект разработчик одобрит эти новые модули, их можно будет добавить в основную ветку.
При этом возможности СКВ не ограничиваются только созданием записей об изменениях и новых веток. По сути, Git — это полноценный модуль управления проектами, который помогает организовать синхронную работу многих программистов.
Зачем нужен GitHub
Не путайте Git и GitHub — это онлайн-сервис, который основан на технологии Git. Он хранит репозитории в интернете, автоматически синхронизирует их с репозиториями на компьютерах разработчиков, следит за обновлениями кода, позволяет редактировать код прямо в репозитории и копировать себе чужие репозитории. Ещё там есть встроенный трекер задач, система уведомлений, форум, переписка между пользователями и комментариями. А всё потому, что GitHub задумывался как социальная сеть для программистов.
GitHub — не единственный онлайн-сервис для работы в СКВ, но самый распространённый.
Нужны ли визуальные интерфейсы
Сам по себе Git — это инструмент для командной строки, у него нет графического интерфейса. Но у него много визуальных приложений, и в них всё бывает довольно красиво. На сайте Git есть ссылки на популярные клиенты:
С такими приложениями нужно иметь в виду один момент. Если в командной строке работа с Гитом будет выглядеть как несколько понятных читаемых строк, то графический интерфейс может поначалу запутать:
Поэтому такие клиенты могут пригодиться, если вы уже продвинутый разработчик и ищете какой-то способ более наглядной работы с разными ветками и репозиториями, чтобы распределять задачи и зоны ответственности. Но для новичков лучше сначала освоить основы работы с Git через командную строку, а там уже можно изучать устройство и принципы работы визуальных расширений.
Установка и настройка Git
Часто Git устанавливается сразу с операционной системой Linux. Чтобы проверить, есть ли он у вас, наберите в терминале командной строки git --version. Если установлен, терминал покажет версию:
Если не установлен, делаем так:
- Открываем страницу загрузки.
- Устанавливаем по инструкции для своей операционной системы. Для Windows понадобится скачать установочный файл, а в MacOS или Linux — установить Git через терминал командной строки.
- Проверяем установку командой
git --versionв терминале.
После установки нужно внести в Git информацию о себе, которая будет сохраняться вместе с коммитами: имя пользователя и адрес электронной почты. Можно без этого, тогда Git будет использовать значения по умолчанию.
git config --global user.name "Имя Пользователя"
git config --global user.email "ваша_почта@example.com"
Если вы хотите использовать удалённые репозитории на онлайн-сервисах типа GitHub или GitLab, пишите почту, с которой регистрировались там. Без этого могут быть сложности в работе.
Можно указать почту и имя пользователя для каждого отдельного проекта. Для этого нужно зайти в корневую папку проекта и указать в терминале, кто делает коммиты на вашем компьютере:
git config user.name "Имя Пользователя"
git config user.email "ваша_почта@example.com"
Создаём репозиторий и делаем первый коммит
Репозиторий можно создать для любого проекта. Если у вас в папке лежит текстовый файл или Excel-таблица, в которые вы что-то записываете, вы можете сохранять их версии в репозитории.
Для этого нужно создать папку и перейти в неё через терминал командой cd:
В папку нужно добавить файлы. Мы добавим документ Word, который будет называться CODE_article_about_Git.docx:
Чтобы создать репозиторий, в котором будут храниться наши коммиты, в терминале пишем команду git init. Терминал скажет, что в папке создана директория с названием .git:
Если у вас настроено отображение скрытого содержимого, вы увидите в директории проекта новый репозиторий git:
Чтобы сделать коммит, файлы в папке нужно подготовить: сказать Git, состояния каких файлов будем сохранять. Для этого используют команду git add и указывают после неё название файла. Это называется отслеживанием файлов:
После этого можно сделать коммит и подписать его. Для первого коммита принято добавлять сообщение Initial commit. Целиком команда выглядит так:
git commit -m "Initial commit"
После изменения файлов в папке проекта нужно будет проделать последние действия ещё раз: подготовить нужные файлы для снимка проекта и сделать коммит с описанием.
Если что, удалять файлы и коммиты тоже можно.
Что ещё умеет Git
Кроме git add и git commit, есть много других команд, которые делают Git мощным и многофункциональным инструментом. Вот некоторые, которые используются чаще остальных.
Git clone скачивает удалённый репозиторий из онлайн-сервиса. Если вы находите какой-то интересный проект на GitHub или другом месте хранения репозиториев, его можно скачать такой командой:
git clone <ссылка на репозиторий>
При этом скачаются только файлы из репозитория — зависимости и другие необходимые для работы компоненты нужно будет установить самостоятельно.
Git branch создаёт новую ветку. После команды нужно задать название:
git branch <имя ветки>
Чтобы переключиться на эту ветку и начать делать коммиты в ней, нужно выполнить ещё одну команду:
git checkout <имя ветки>
Git status выдаёт информацию о текущей ветке:
Что мы тут видим:
- Название ветки — main.
- Список отслеживаемых и неотслеживаемых файлов, которые можно добавить в коммит. Сейчас в папке проекта только один неотслеживаемый файл .DS_Store, созданный операционной системой.
- Изменения после последнего коммита и наличие неотслеживаемых файлов.
Git pull скачивает обновления с удалённого репозитория. Например, когда главный разработчик добавляет изменения в основную ветку, остальные должны скачать обновлённую версию.
Git push выполняет обратное — отправляет изменения с активной ветки разработчика на удалённый репозиторий.
Если хотите увидеть полный список самых основных команд, наберите в терминале команду git --help:
Как освоить работу с Git
Гит — стандарт знаний для любого разработчика, но нет смысла учить все возможности и команды заранее. Достаточно разобраться в принципе работы и запомнить основы. А когда начнёте программировать, то быстро выучите всё остальное.
Чтобы чаще практиковаться, возьмите за правило каждый раз, когда пишете какой-то код, создавать репозиторий и работать вместе с ним.
Один из вариантов познакомиться с Git и его возможностями поближе — пройти онлайн-игру learngitbranching.js.org. Так вы увидите, как всё это выглядит визуально:
Другой вариант — пойти на курс «Основы работы с Git». Тогда, кроме Git, вы узнаете много полезных вещей и закрепите их на практике так, как делают настоящие разработчики в реальной жизни.
