Создание Git-репозитория - Основные команды - Система управление версиями

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

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

Исходный проект --> Копия проекта

Допустим, что работа с копией прошла успешна и на каком-то этапе нам нужно сохранить именно эту копию. Получается, что у нас будет уже три папки с проектом.

Исходный проект --> Копия проекта --> Копия копии проекта

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

Что такое GIT

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

Для этого были придуманы системы контрольных версий. Предлагается работать с самой популярной из них - это GIT.

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

Что дает GIT

В чем достоинства системы управления версиями GIT?

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

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

И третье достоинство GIT - это возможность работать с проектом, в котором участвует несколько разработчиков. На практике так происходит очень часто. В компаниях, над крупными проектами работают десятки/сотни и даже тысячи человек. И без GIT, без репозитория это было бы невозможно.

Как это происходит? Об этом немного ниже.

А пока ответим на такой вопрос: нужно ли использовать систему управления версиями GIT, если над проектом работает один человек?
Ответ: ДА. Нужно.

Ситуации могут быть разными. Например, заказчик может потребовать вернуть изменения, которые проводились месяц назад. В этом случае иметь контрольные точки будет очень удобно. Или же случилась потеря файлов/возникла путаница и т.п. А репозиторий можно загрузить на удаленный сервер и таким образом застраховаться.

GIT и GitHub

Рассмотрим еще один момент прежде чем начнем устанавливать GIT на персональный компьютер.

Есть GIT, а есть GitHub и это разные вещи. Что такое GIT - этому было дано определение выше. А GitHub - это удаленное хранилище репозиториев - github.com.

Итак, GIT - это программа для создания репозиториев, а GitHub - это удаленное хранилище репозиториев.

Начало работы - GIT How To

Теперь начнем работать с системой управления версиями GIT. Для этого переходим на сайт по ссылке git-scm.com. Скачиваем версию GIT для своей операционной системы (я использую ОС Windows 10) и устанавливаем GIT как обычную программу.

Далее на этой странице мы познакомимся с основными/базовыми возможностями и функциями системы управления версиями GIT. Для тех, кто хочет получить больше знаний, существует интерактивный тур GIT How To - githowto.com/ru, который познакомит вас с основами GIT.

Git GUI или Терминал?

Для работы с системой управления версиями GIT можно использовать его графический интерфейс Graphical User Interface.

Что бы запустить Git GUI нужно открыть любую папку и при клике правой кнопки мыши из контекстного меню нужно выбрать пункт Git GUI Here. Либо открыть Git GUI через меню Пуск.

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

Работа с терминалом

В операционной системе Windows, чтобы открыть терминал нужно сделать следующее:

- открыть любую папку, а лучше перейти в папку с проектом;

- зажимаем клавишу Shift и при клике правой кнопки мыши из контекстного меню следует выбрать пункт Открыть окно команд или на английском языке Open PowerShell window here.

Если терминал запущен из произвольного каталога, то уже находясь в терминале, нужно перейти в каталог/папку с проектом. Для этого используется команда cd (change directory), после которой необходимо указать путь к проекту.

Есть более простой способ - работать с терминалом непосредственно в редакторе VScode.

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

Создание репозитория - Команда git init

Приступаем к работе с GIT. Для этого, находясь в терминале вводим команду git init (инициализация git).

Все команды GIT (большая их часть) начинается с git.

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

Настройка GIT - Локальная и глобальная конфигурация

После создания репозитория нужно настроить систему управления версиями GIT. Что это значит?

Дело в том, что как правило над проектом работает не один человек. И чтобы понимать, кто какие изменения внес, необходимо так сказать представиться: указать свое имя и e-mail. Поэтому для начала необходимо прописать две конфигурационные команды.

В системе управления версиями GIT мы можем конфигурировать файлы как локально, так и глобально. Начнем с локальной конфигурации. Итак, поочередно вводим команды:

git config --local user.name "Anton"

git config --local user.email my_mail@mail.ru

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

Рекомендация: если вы впервые установили GIT, то желательно применить глобальные настройки

Для этого необходимо снова запустить выше указанные команды. Только в них local нужно заменить на global.

git config --global user.name "Anton"

git config --global user.email my_mail@mail.ru

Как работает система GIT

Теперь можно перейти непосредственно к тому, как работает система управления версиями GIT?

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

1-е состояние - это когда файлы только созданы. Здесь все просто: допустим мы создали файл index.html, он просто лежит в проекте и с ним ничего не происходит.

2-е состояние - это когда GIT следит за файлами, при этом файлы попадают в так называемый индекс.

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

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

Статус репозитория - Команда git status

Начнем с того что посмотрим статус репозитория. Для этого используется команда git status.

Что мы видим?

1. Что у нас еще нет ни одного коммита - ни одной контрольной точки - No commits yet.

2. Далее идет список не отслеживаемых файлов (untracked files - об этом мы говорили - это первое состояние, когда файлы существуют, но с ними ничего не происходит, они не отслеживаются).

3. И еще ниже предлагается использовать команду git add для отслеживания.

Файлы в индексе - Команда git add

Добавим файлы в индекс, используя команду git add.

git add -A - эта команда означает, что GIT будет следить за всеми файлами проекта (git add All). Что мы в результате и видим: сообщение Changes to be committed говорит о том, что произошли изменения, подлежащие фиксации. Таким образом в GIT-репозитории файлы находятся во 2-м состоянии - в состоянии слежения. И далее приведен список файлов, за которыми будет следить система управления версиями GIT.

Но коммитов по-прежнему нет - No commits yet.

Здесь же мы видим предупреждение: warning: LF will be replaced by CRLF in .jshintrc.
The file will have its original line endings in your working directory. Что это значит?

Дело в том, что в разных операционных системах принят разный формат символов, обозначающий перевод строк:
- Windows - \r\n или CRLF (код 0D0A);
- Unix - \n или LF (код 0A);
- Mac - \r или CR (код 0D).

Из этого сообщения мы видим, что файл .jshintrc был создан в unix-подобной операционной системе и в нем будет заменен формат перевода срок на CRLF, т.е. на тот, что принят в ОС Windows.

Мы еще вернемся к вопросу о различиях переноса строк в проектах, разрабатываемых в разных ОС. А пока переходим к 3-му состоянию файлов в GIT.

Создание коммита - Команда git commit

Третье состояние файлов в GIT называется коммит, при котором система управления версиями фиксирует сделанные изменения - создается контрольная точка.

Для создания коммита используется команда git commit, которая имеет следующий синтаксис git commit -a -m"first point", где:

- git commit - сама команда;

- -a - означает All, то есть коммит (контрольная точка) будет затрагивать все файлы проекта;

- -m"first point" - это обязательная часть команды git commit, где -m означает message - сообщение/описание коммита. "first point" - это само сообщение (может быть любым/произвольным и обычно оно более информативно).

Все прошло успешно - была создана контрольная точка. При этом, если снова ввести команду git status, то мы увидим, что ничего не надо делать, рабочее дерево чистое (nothing to commit, working tree clean).

Внесение и отмена изменений - Команда git restore

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

Мы видим сообщение о модификации/изменении файла index.html. При этом система управления версиями GIT предлагает варианты возможных дальнейших действий: использовать команду git add, с которой мы уже знакомились или команду git restore, чтобы отменить изменения в рабочем каталоге (to discard changes in working directory) до состояния предыдущего коммита.

Теперь, как и подсказывает GIT в последнем примере: no changes added to commit (use "git add" and/or "git commit -a"), мы снова:

- добавим в индекс файл index.html, в котором произошли изменения (команда git add);

- и создадим новый коммит (новую контрольную точку).

Просмотр комитов - Команда git log

Теперь, когда есть несколько коммитов (несколько контрольных точек), при помощи команды git log мы можем посмотреть логи (log/журнал) того, какие коммиты были/есть.

Здесь мы видим созданные коммиты, а также кто и когда их сделал.

Теперь, когда мы научились локально работать с контрольными точками GIT-репозитория, можно переходить к следующему шагу: выложить GIT-репозиторий в Интернет?

Копия репозитория - git push -u origin main

Как сделать Backup - копию репозитория? Как выложить репозиторий на GitHub?

Для начала нужно зарегистрировать на сервисе GitHub, о котором шла речь в начале статьи.

После регистрации появится возможность создать новый репозиторий New Repository.

Здесь нужно выбрать флаг Private - You choose who can see and commit to this repository - Вы выбираете, кто может видеть и фиксировать (оставлять коммиты) этот репозиторий.

После этого мы увидим следующее:

Выбираем вариант push an existing repository from the command line - добавить существующий репозиторий из командной строки. Для этого нужно:

Скопировать команду, выделенную на иллюстрации синим цветом и вставить в терминал программы VScode.

git remote add origin https://github.com/veavl/udemy_RU_02.21.git

Что делает эта команда? Что при этом происходит?

В папке, содержащей локальный репозиторий, мы запускаем команду git remote add origin - при этом устанавливается подключение к удаленному серверу и git репозиторию на нем:
- git - это должно быть обязательно;
- remote add - сама команда;
- origin - имя удаленного репозитория, которое дается по умолчанию и далее url-адрес к нему https://github.com/veavl/udemy_RU_02.21.git.

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

Вторая команда git push -u origin main позволяет отправить локальный репозиторий на сервер.

push в программировании означает заталкивание элемента в массив/стек, или git-ветки на удаленный репозиторий.

- origin - имя удаленного репозитория и main - это ветка удаленного репозитория.

-u - это ключ, который устанавливает связь с веткой main. Этот ключ указывается единожды. В дальнейшем при использовании команды git push отправка локальных данных на сервер будет связана именно с веткой main

То есть при следующей отправке локального репозиторий на сервер команда git push -u origin main сокращается до git push.

Ошибка - error: failed to push some refs

При попытке выполнить команду git push -u origin main возможно появление ошибки: error: failed to push some refs to 'https://github.com/veavl/udemy_RU_02.21.git'

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

Дело в том, что на GitHub произошли изменения, касающиеся того, что ветка master меняет название на main. И чтобы подобной ошибки не возникало можно пойти двумя путями:

Выполнить туже команду, только вместо ветки main указал ветку master. И тогда все пройдет успешно.

Второй вариант указан на сайте GitHub (это также отражено на иллюстрации выше): перед выполнением команды git push -u origin main следует выполнить команду git branch -M main, после которой в локальном репозитории главная ветка также будет носить имя main.

Команда git branch -M main переименовывает ветку master на локальном репозитории в main. Таким образом, изменения, произошедшие на удаленном репозитории больше не конфликтуют с локальным хранилищем, в котором главная ветка стала также называться main.

Теперь осталось проверить результат проделанной работы: удалось ли нам заpush-ить "затолкнуть" наш локальный репозиторий на удаленный сервер.

Все прошло успешно. Все файлы локального проекта теперь есть и на удаленном репозитории: это файл index.html и папка js, содержащая файл script.js.

И если кликнуть на второй контрольной точке second point (на втором коммите), то будут отображаться изменения, сделанные в файле index.html. Это видно на нижней иллюстрации: были изменения в теге title.

На этом все. Мы учились работать с системой контроля версиями GIT и с сервисом GITHub. Здесь нет ничего сложного: главное знать основные команды GIT и порядок их выполнения.

Отзывы и комментарии:

Комментариев нет...

Оставить отзыв:

Ваше Имя:

Текст комментария:

Ответьте на вопрос:

Сколько дней в Високосном году?

Работа с системой контроля версий GIT и сервисом GITHub