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

Версионирование

Чтобы лучше понять проблему версионирования, рассмотрим пример дизайнера, который закончил работать над проектом и отправил финальную версию заказчику. У дизайнера есть папка, в которой хранится финальная версия проекта:

source/
barbershop_index_final.psd

Всё хорошо, дизайнер закончил работу, но заказчик прислал в ответ правки. Чтобы была возможность вернуться к старой версии проекта, дизайнер создал новый файл barbershop_index_final_2.psd, внёс изменения и отправил заказчику:

source/
barbershop_index_final.psd
barbershop_index_final_2.psd

Этим всё не ограничилось, в итоге структура проекта разрослась и стала выглядеть так:

source/
barbershop_index_final.psd
barbershop_index_final_2.psd
…
barbershop_index_final_19.psd
…
barbershop_index_latest_final.psd
barbershop_index_latest_final_Final.psd

Вероятно, многие уже сталкивались с подобным, например, при написании курсовых работ во время учёбы. В профессиональной разработке создавать новые файлы для версионирования — плохая практика. Обычно у разработчиков в папке проекта хранится множество файлов. Также над одним проектом может работать несколько человек. Если каждый разработчик для версионирования будет создавать новый файл, немного изменяя название предыдущей версии, то в скором времени в проекте начнётся хаос и никто не будет понимать, какие файлы нужно открывать.

Git

Для решения проблемы с сохранением новой версии файлов удобно использовать системы контроля версий. Одна из самых популярных — Git. Работу Git можно сравнить с процессом сохранения и загрузки в компьютерных играх:

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

Папка с данными игры могла бы выглядеть так:

SomeGame/
| - saves
|  | - save001.sav
|  | - save002.sav
|  |   …
|  |   папка с сохранениями
|
| - game.exe
|   ...файлы игры

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

Основные понятия

Список терминов, которые будут вам полезны.

Репозиторий

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

Рабочая область и хранилище

barbershop/
        | - .git
        |  | - bea0f8e
        |  | - hb-427307464A
        |  |   Хранилище
        |
        | - css
        | - index.html
        |   Рабочая область

Корневая папка проекта — это рабочая область. В ней находятся все файлы и папки, необходимые для его работы.

Хранилище — это содержимое скрытой папки .git. В этой папке хранятся все версии рабочей области и служебная информация. Этим версиям система автоматически даёт название, состоящее из букв и цифр. В примере выше — это bea0f8e и d516600. Не стоит проводить манипуляции с папкой .git вручную. Вся работа с системой производится командами через специальные приложения или консоль.

Коммит

Точно так же, как и в игре, в системе контроля версий Git можно сохранить текущее состояние проекта. Для этого есть специальная команда — commit. Она делает так, что новая версия проекта сохраняется и добавляется в хранилище. В файле с сохранением отображаются: все изменения, которые происходили в рабочей области, автор изменений и краткий комментарий, описывающий суть изменений. Каждый коммит хранит полное состояние рабочей области, её папок и файлов проекта.

В итоге проект работает так:

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

Система контроля версий Git

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

Работа в команде

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

Репозитории можно синхронизировать между пользователями
Репозитории можно синхронизировать между пользователями

Этот способ сложный и редко используется. Чаще всего разработчики синхронизируют локальный репозиторий с удалённым. Удалённый репозиторий — это тот же репозиторий, только его данные находятся в облаке.

Синхронизация через удалённый репозиторий
Синхронизация через удалённый репозиторий

Этапы синхронизации

Как сделать так, чтобы разработчик смог передать актуальную версию проекта коллеге?

Для взаимодействия с системой Git в консоль вводятся специальные команды. Не пугайтесь, работу с консолью можно будет заменить на работу с одной из программ, о которых расскажем ниже. Но чтобы лучше понимать суть, придётся запомнить несколько команд. Все они начинаются с ключевого слова git. Для синхронизации есть две основных команды: pull (англ. «тянуть») и push (англ. «толкать»).

Pull

Если работа над проектом ведётся в команде, то перед тем как начать писать код, нужно получить последнюю версию проекта. Для этого нужно выполнить команду pull. Так мы забираем все изменения, которые были совершены со времени последней синхронизации с удалённым репозиторием. Теперь они у нас в репозитории на локальном компьютере.

Push

Чтобы отправить коллегам последнюю версию проекта выполняем команду push. Если в удалённом репозитории с момента последней синхронизации не было никаких изменений, то все сохранённые изменения успешно загрузятся в облако, и коллеги получат последнюю версию проекта, выполнив команду pull. Если же были изменения, то Git попросит вас перед отправкой подтянуть последние версии, сделав pull.

Синхронизация (push и pull) между локальными и удалённым репозиториями
Синхронизация (push и pull) между локальными и удалённым репозиториями

Типовой рабочий процесс с использованием Git

Разберём типовой процесс разработки сайта в команде. Представим, что Игорь и Алиса — разработчики на одном проекте. Игорь начал верстать проект и сделал первые коммиты, в которых зафиксировал изменения в файле index.html. Для схематичности названия коммитов будут простые: B1 и B2.

Коммиты B1 и B2
Коммиты B1 и B2

После того как Игорь сделал два коммита, он захотел отправить свои изменения в удалённый репозиторий. Чтобы их передать, Игорь выполнил команду git push. После чего в облаке появилось две версии проекта. То есть Игорь отправил не только финальную версию проекта, но и все сохранённые изменения.

Игорь запушил свои коммиты
Игорь запушил свои коммиты

После пуша данные синхронизировались с удалённым репозиторием. Но как Алисе теперь получить изменения? Для этого она выполняет команду git pull и получает все изменения из облака к себе на компьютер. Таким образом, состояние проекта у Игоря и Алисы синхронизировались, и они могут дальше продолжить работать над ним.

Данные у обоих разработчиков синхронизировались
Данные у обоих разработчиков синхронизировались

Параллельные изменения

Что произойдёт, если разработчики изменят одинаковый файл и сделают push? Предположим, что Игорь и Алиса изменили файл index.html, сделали коммит с изменениями и запушили его. Игорь оказался быстрее Алисы и сделал push первым.

Два пуша в одно время?
Два пуша в одно время?

В этом случае Git сообщит Алисе, что нельзя пушить свои изменения, потому что она не делала pull. Дело в том, что после того как Игорь синхронизировался с удалённым репозиторием, версия проекта Алисы стала отличаться от той, что находится на удалённом репозитории, и Git это видит. Система сообщает, что перед тем, как выполнить команду push, нужно выполнить pull, чтобы забрать изменения. Алиса делает pull и ей вновь приходит уведомление от Git. В этот раз он сообщает Алисе о том, что произошёл конфликт.

Конфликт

Дело в том, что Игорь и Алиса изменили одинаковый файл и теперь Алисе предстоит решить конфликт.

Конфликт
Конфликт

Существуют два вида конфликтов:

  1. Автоматически разрешаемый конфликт.
  2. Конфликт, который нужно разрешить вручную.

Ниже рассмотрим оба варианта.

Слияние

Допустим, что на третьей строке Игорь добавил в проект шапку, а на четвёртой Алиса добавила футер.

Игорь сделал шапку и отправил коммит, а Алиса добавила подвал
Игорь сделал шапку и отправил коммит, а Алиса добавила подвал

Git видит, что произведённые изменения не затрагивают друг друга. Он сам объединит две версии проектов в одну, совершив слияние. После этого Алиса спокойно синхронизируется с удалённым репозиторием, отправив новую версию проекта.

Изменения в проекте не пересекались и Git выполняет слияние сам
Изменения в проекте не пересекались и Git выполняет слияние сам

Во время слияния Git не знает, в каком порядке расположить коммит В3 Игоря и коммит В4 Алисы, из-за которых случился конфликт. Поэтому Git разрешает существовать нескольким версиям проекта одновременно. Как раз для этого и нужен следующий коммит В5, в котором происходит слияние предыдущих параллельных версий. После того как Алиса запушит изменения, она отправляет все версии проектов на удалённый репозиторий. В следующий раз, когда Игорь сделает pull, он получит полную историю со слиянием конфликта.

Слияние
Слияние

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

Алиса и Игорь изменили один и тот же блок
Алиса и Игорь изменили один и тот же блок

В таком случае Git не знает чья версия проекта правильная и поступает очень просто. Он изменяет файл index.html, добавляя в него изменения и Игоря и Алисы. После этого предупреждает Алису о конфликте и просит выбрать правильный вариант.

Версии файла
Версии файла

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

Окружение Git

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

GitHub

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

GUI

Облегчить работу с Git и GitHub могут специальные программы. Такие программы в удобной форме показывают изменения в коде, список коммитов и обладают другими удобными возможностями. Обычно в подобных программах есть возможность выполнять стандартные Git команды: pullpushcommit и прочие — просто нажав на кнопку.

Следующая глава

Глава 2. Словарь терминов для Git и GitHub

Собрали основные термины, использующиеся в Git и GitHub.

Сложность: ⭐


«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

Читать дальше

5 частых ошибок при работе с Git

5 частых ошибок при работе с Git

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

Читать дальше
Git
  • 27 августа 2023
Работа с Git через консоль

Работа с Git через консоль

Задача: форкнуть репозиторий в GitHub, создать ветку и работать с кодом.

Сразу появляется много вопросов — что такое GitHub, какие для этого нужны команды, зачем, а главное, как всем этим пользоваться? Давайте разберёмся.


Больше из рубрики Git: введение, основные команды, решение проблем.


Когда мы пишем код, мы постоянно туда что-то добавляем, удаляем, и иногда всё может ломаться. Поэтому перед любыми изменениями стоит сделать копию проекта. Если собирать проекты в папки с именами проект1проект1_финали проект2_доделка, вы быстро запутаетесь и точно что-нибудь потеряете. Поэтому для работы с кодом используют системы контроля версий.

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

Git — самая популярная система контроля версий. С Git можно работать через командную строку (или терминал). В каждой системе своя встроенная программа для работы с командной строкой. В Windows это PowerShell или cmd, а в Linux или macOS — Terminal. Вместо встроенных программ можно использовать любую другую — например, Git Bash в Windows или iTerm2 для macOS.

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

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

Читать дальше
Git
  • 7 августа 2023
GitHub Desktop: обзор и первая настройка

GitHub Desktop: обзор и первая настройка

Самая короткая инструкция о том, как сохранить файлы в GitHub и ничего не сломать. И самое главное — никакой консоли, всё через окошки и с помощью мышки. Для этого используем GitHub Desktop.

Внимание! GitHub Desktop не работает на Windows 7×32, поэтому если у вас эта версия системы, обновитесь до Windows 10 или воспользуйтесь программой GitKraken.

В этой статье идёт рассказ о системах контроля версий. Если вы совсем ничего о них не знаете, прочитайте статьи «Словарь терминов для Git и GitHub» и «Введение в системы контроля версий», чтобы понять терминологию и разобраться, зачем мы вообще это делаем.

Читать дальше
Git
  • 7 августа 2023
Как склеить коммиты и зачем это нужно

Как склеить коммиты и зачем это нужно

Когда вы открываете пулреквест и ваш код смотрят и комментируют другие, бывает нужно что-то исправить. Обычно такие изменения мы комментируем сообщением вроде «Увеличил шрифт на 2px» или «Поменял оттенок фона в шапке». Такие маленькие изменения интересны, только пока они в пулреквесте. Ревьювер (человек, который смотрит ваш код), может легко узнать, что и когда вы изменили, а не читать весь diff заново, а вы можете легко откатить коммит, если он не нужен. Но когда приходит время вливать пулреквест, эти маленькие коммиты теряют свою ценность. Поэтому лучше их склеить в один.

Читать дальше
Git
  • 14 июня 2023
Основные команды для работы с Git

Основные команды для работы с Git

Работа с Git через терминал — это обязательная часть практики фронтендера. Однако для начинающих разработчиков этот инструмент может показаться сложным. Чтобы вам было проще учиться, мы собрали основные команды для работы с Git.

☝ В некоторых командах мы будем писать URL-адрес удалённого репозитория и название проекта в квадратных скобках, вот так — [ссылка на удалённый репозиторий]. Мы делаем это только для наглядности. Вам квадратные скобки ставить не нужно.

Читать дальше
Git
  • 22 февраля 2023
Как бесплатно залить сайт на GitHub Pages

Как бесплатно залить сайт на GitHub Pages

Допустим, вы сделали какой-то проект, например, собрали себе портфолио по шаблону, и теперь хотите выложить его в интернет. Если вы использовали только HTML и CSS, то необязательно платить деньги, чтобы загрузить сайт куда-то. Вы можете бесплатно выложить сайт на сервис GitHub Pages. Всё, что нужно — аккаунт на Гитхабе.

Читать дальше
Git
  • 29 ноября 2022
Регистрация на GitHub

Регистрация на GitHub

Создание нового аккаунта на GitHub состоит всего из 10 шагов — и вся регистрация занимает меньше пяти минут.

💫 Обратите внимания, что интерфейс Гитхаба регулярно меняется, так что внешне он может отличаться, когда вы читаете эту статью.

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

Ввод почты. На следующем шаге начинается регистрация. Подтвердите свою почту с прошлого шага и нажмите Continue (Продолжить).

Пароль. Придумайте сложный пароль, чтобы его никто не взломал. Например, Гитхаб просит, чтобы в пароле было не меньше 15 символов или 8 символов, но тогда должны быть и латинские буквы, и цифры.

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

Если имя недоступно, Гитхаб вам об этом скажет. А если доступно — жмите Continue.

Мне сложно работать после выходных. Что делать

Рассылки. Дальше Гитхаб спросит, хотите ли вы подписаться на рассылку об обновлениях. Впечатайте латинскую У, если хотите, или n, если письма вам не нужны. Готовы спорить, мы знаем, что вы выберете.

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

Подтверждение почты. После капчи вам придёт письмо с кодом на почту. Введите его на следующей странице.

Вот здесь. Главное — не ошибайтесь.

Общая информация о вас и вашей команде. Если вы регистрируете аккаунт для себя, выбирайте Just me. Второй пункт — студент вы или учитель. Выбирайте «Студент», если вы не учитель.

Интересы. Дальше Гитхаб спросит вас об интересах — то есть о том, зачем вы регистрируете аккаунт. Из вариантов:

  • Совместная разработка и код ревью.
  • Автоматизация. CI/CD, API и другие админские вещи.
  • Безопасность. Двухфакторная аутентификация, ревью, сканирование кода и списки зависимостей.
  • Приложения. Выбирайте, если будете использовать GitHub Mobile, CLI, Desktop.
  • Управление проектами. Проекты, метки, ишьи, вики и другие управленческие дела.
  • Управление командами. Организации, приглашения, роли, домены.
  • Сообщество. Выбирайте, если Гитхаб интересен вам как соцсеть.

Вы можете выбрать несколько пунктов или пропустить и не указывать ничего, для этого пролистайте страницу вниз для кнопки Skip customization.

Выбор тарифа. На выбор бесплатный тариф или платный GitHub Pro. Практика показывает, что для большинства личных проектов хватит бесплатного тарифа. В сентябре 2022 в него входили:

  • Безлимитное количество репозиториев.
  • 2000 минут CI/CD в месяц.
  • 500 мегабайт места в хранилище пакетов.
  • Поддержка сообщества.

Выбор тоже можно пропустить, тогда у вас будет бесплатный тариф.

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

Читать дальше
Git
  • 28 сентября 2022
Работа с Git в Visual Studio Code

Работа с Git в Visual Studio Code

Если вы вёрстаете сайты или пишете код в редакторе Visual Studio Code, то Git за пять минут настраивается прямо внутри редактора. Не нужно запоминать команды для консоли, не нужно тыкать в лишние приложения.

Следуйте инструкции и всё получится.


Другие способы работать с Git: в терминале, в GitHub Desktop.


Читать дальше
Git
  • 16 сентября 2022
Markdown за 5 минут

Markdown за 5 минут

Маркдаун, он же markdown — удобный и быстрый способ разметки текста. Маркдаун используют, если недоступен HTML, а текст нужно сделать читаемым и хотя бы немного размеченным (заголовки, списки, картинки, ссылки).

Главный пример использования маркдауна, с которым мы часто сталкиваемся — файлы readme.md, которые есть в каждом репозитории на Гитхабе. md в имени файла это как раз сокращение от markdown.

Другой частый пример — сообщения в мессенджерах. Можно поставить звёздочки вокруг текста в Телеграме, и текст станет полужирным.

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

Читать дальше
Git
  • 5 октября 2021