Начать занятия
I am ready for a long road flight for working with a week- or months-long projects.
Начать обучение
  • Блог
    →
  • Введение в Git/GitHub: установка и настройка

Введение в Git/GitHub: установка и настройка (ч. 7)

Введение

В предыдущей статье мы рассмотрели наиболее часто используемые команды при работе в консоли. В данной публикации продолжим осваивать этот инструмент, используя его для взаимодействия с системой контроля версий (Version Control System, СКВ) Git, а также с его неизменным спутником, хранилищем кода, GitHub.

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

Одной из важнейших тем, которую необходимо изучить начинающему разработчику, а также освоить сопутствующие ей приложения, является СКВ. Это must have инструмент для любого программиста, с которым в обязательном порядке нужно уметь работать.
Чтобы было понятнее, что такое СКВ, приведем ряд примеров и задач, которые она призвана решать:
1
Программист устраивается в компанию, где ему предстоит работать над одним проектом с другими разработчиками. Каким образом он сможет предоставлять свой код коллегам и получать доступ к их наработкам: с помощью какого-то мессенджера, электронной почты, соц. сетей? А если над проектом работает не один десяток или сотня людей, которые используют код друг друга и меняют его ни по одному разу в день?
2
Программист написал работающий код, но, увлекшись его оптимизацией, испортил свою часть работы, да еще и затронул код коллег, от чего программа стала работать не корректно. Как решить такую проблему и вернуться к рабочей версии кода: жать до посинения Ctrl + Z, чтобы откатиться к ней? А если среда разработки не запомнила все изменения и отменить уже ничего нельзя?
3
Внешняя компания, помогающая разрабатывать приложение, прислала патч с кодом, содержащим ошибку, которую никто вначале не заметил. Из-за этого программа стала уязвима для хакерских атак. Специалист по информационной безопасности спустя какое-то время обнаружил брешь и решил выяснить, кто был автором уязвимого кода. Узнать это не имея на руках все изменения, которые были внесены в проект, достаточно проблематично.
Для решения этих и множества других задач необходимо иметь простой и удобный инструмент, который позволял бы:
  • отслеживать все изменения в коде, которые были внесены разработчиками
  • обмениваться кодом внутри команды
  • хранить все промежуточные версии файлов
  • отменять внесенные изменения в код, откатываясь до любой рабочей версии подобно точкам восстановления в Windows
  • видеть, кто и когда вносил изменения в файлы
Для таких ситуаций и были придуманы СКВ, которые стали отраслевым стандартом как для командной разработки, так и среди индивидуальных программистов.
Следует заметить, что СКВ используют не только программисты, но и писатели, дизайнеры, переводчики — все, кому требуется хранить промежуточные версии своих наработок.

2. Виды СКВ

СКВ бывают локальными (ЛСКВ), централизованными (ЦСКВ) и распределенными (РСКВ).

2.1. Первое поколение СКВ

В первом поколении СКВ были локальными: они хранили все изменения файлов на одном устройстве в локальной базе данных. При этом разрешалось только одному пользователю одновременно вносить изменения в файл. Если требовалось поработать с файлом, то необходимо было получить его из репозитория, как книгу в библиотеке. Далее этот файл блокировался до тех пор, пока запросивший его разработчик не возвращал его обратно — до тех пор никто другой не мог его редактировать.
Такие системы не предназначены для удобного взаимодействия с удалённой командой. Примером ЛСКВ является VSS, SCCS и RCS.

2.2. Второе поколение СКВ

Для решения проблем ЛСКВ были созданы ЦСКВ, которые используют центральный сервер для хранения всех версий файлов. А уже к нему по сети подключаются разработчики для получения, хранение файлов и т. д. Эти системы впервые позволили нескольким разработчикам одновременно работать с одними и теми же файлами. Использование ЦСКВ являлось стандартом на протяжении многих лет. К ним относятся CVS, SVN и т. д.
ЦСКВ позволяет взаимодействовать между собой удаленным участникам, но при этом все привязаны к одному серверу, где хранятся файлы проекта, что является серьезным недостатком. Если он вдруг станет недоступен или повредится жесткий диск, то ни один из его клиентов не сможет использовать контроль версий, да и это чревато повреждением файлов и потерей части проекта.

2.3. Третье поколение СКВ

С целью устранения недостатков ЦСКВ были разработаны системы третьего поколения или РСКВ такие, как Git, Mercurial, Bazaar. В данных системах клиенты скачивают к себе на локальный компьютер полностью весь проект со всеми файлами и их изменениями за все время его существования. И если один из серверов выйдет из строя, то потерянный код можно будет восстановить, взяв его у любого программиста из команды, и загрузить на общий сервер для продолжения работы.
РСКВ прекрасно зарекомендовали себя в командной работе вне зависимости от того, в какой части света находятся сотрудники.
В конечном итоге Git оставил позади всех своих конкурентов, которые, не смотря на это, до сих пор используются разработчиками во всем мире.
Поколения СКВ

3. СКВ Git

Git — самая популярная, бесплатная РСКВ с открытым исходным кодом, которая позволяет отслеживать любые изменения в файлах, работать над одним проектом совместно с коллегами, обмениваться кодом и многое другое. С историей возникновения Git можно ознакомиться по ссылке.
Распределенность Git означает, что работоспособность системы не зависит от одного центрального сервера, хранящего файлы. Вместо этого любой клиент имеет у себя на компьютере полную версию репозитория (хранилища кода) с историей изменений, сделанными за все время существования проекта. Т. е. код проекта распределяется одинаково между всеми участниками.
Некоторые путают Git и GitHub, но это не одно и тоже. Git — это программа (консольная утилита), которую устанавливает у себя программист для отслеживания и внесения изменений в файлах. GitHub — это сайт (хостинг) для хранения этих изменений и обмена файлами проекта. Его еще называют социальной сетью для программистов. Существуют и другие подобные сайты, например, BitBucket, SourceForge, GitLab и т. д.
Если кратко, то первоначальное взаимодействие Git и GitHub выглядит так:
1
Регистрация на github.com
2
Создание пустого репозитория
3
Скачивание, установка и настройка Git
4
Подключение его к своему проекту
5
Перенос файлов с помощью Git со своего компьютера на GitHub (в облако) для доступа к ним другим участникам команды (или только для себя)
Оставшаяся часть статьи будет посвящена всем перечисленным выше этапам (кроме 5го пункта, который мы рассмотрим в следующей статье).

4. Создание аккаунта и репозитория на GitHub

4.1. Создание аккаунта

Перейдите на сайт github.com и в правом верхнем углу страницы, для регистрации, нажмите Sign up.
Введите свои данные: электронную почту; пароль (рекомендации по созданию надежного пароля); имя, которое будет использоваться на GitHub и подтверждение на рассылку.
После регистрации, на указанную почту, придет письмо: откройте в нем ссылку для подтверждения своего электронного адреса.

4.2. Создание репозитория

Следующим шагом является создание на GitHub нового репозитория.
Репозиторий — это просто хранилище для чего угодно. В нашем случае, мы будем хранить в нем код. Репозиториев можно создать неограниченное количество под любой проект. Например, сейчас мы создадим хранилище под названием startjava2 (вам цифру 2 писать не нужно). А в будущем еще несколько под разными названиями: basejava, topjava — в них будет храниться код, связанный с этими проектами.
Чтобы создать новый репозиторий, нажмите на сайте GitHub в правом верхнем углу + и выберите New repository.
Откроется новая страница с первоначальными настройками, где нужно ввести имя репозитория и краткое описание (необязательно). Также необходимо пометить, чтобы он был Public (при Private доступ к репозиторию будет только по приглашению). Все остальное мы настроим позже.
Нажав Create repository, вас перекинет на страницу со ссылкой на созданный репозиторий и набором стандартных команд, которыми мы воспользуемся в следующей статье (сейчас вам их использовать не нужно).
Репозиторий создан!

5. Скачивание и установка Git

Скачаем Git с официального сайта и установим к себе на компьютер. Мне нужна версия под Windows.
Запустим скачанный файл для начала установки.

6. Способы авторизации

Доступ к репозиториям на GitHub из командной строки можно получить двумя способами: по протоколу HTTPS или SSH.
С 13 августа 2021 г. GitHub отменил использование паролей для аутентификации из командной строки с помощью Git в пользу токенов персонального доступа (Personal access tokens, PAT). Эти шаги были сделаны с целью повышения безопасности пользователей.

6.1. Токен персонального доступа и HTTPS

Для доступа (авторизации) к GitHub по протоколу HTTPS необходимо создать PAT.
Преимущества PAT перед паролями:
1
Возможность генерации токена для каждого устройства, с которого необходимо получать доступ к репозиторию на GitHub
2
Возможность настройки ограничений для каждого токена при работе с GitHub
3
Возможность аннулирования токена для конкретного устройства
4
Возможность ограничить срок действия токена

6.1.1. Создание токена

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

Относитесь к своим токенам как к паролям, держа их в секрете.
Полученный токен необходимо использовать в командной строке вместо пароля при выполнении операций Git через HTTPS (вы это поймете, когда Git потребует аутентифицироваться).
При запросе аутентификации, вам нужно будет ввести:

Username: ваш email
Password: ваш скопированный токен (вместо пароля)
По завершению срока работы токена, вам на почту придет письмо, сообщающее о том, что его следует продлить. Просто перейдите по ссылке из письма и перегенерите токен.

6.2. Доступ через SSH

Если среди начинающих программистов про HTTPS знают все, то про SSH многие даже и не слышали. Исправим это, проведя вводный ликбез, а заодно и узнаем про доступ к GitHub через данный протокол.
Хотя авторизация на основе SSH считается наиболее безопасной, ее правильная настройка часто может быть проблемой. С другой стороны, PAT зачастую гораздо проще настроить, но при этом они гораздо менее безопасны.
SSH (Secure SHell, «безопасная оболочка») — это сетевой протокол, обеспечивающий шифрование передаваемых данных, а также защищенный доступ к удаленному серверу.
Подключаться к удаленному серверу через SSH можно как с помощью пароля, так и посредством двух ключей (публичного и приватного), которые необходимо создать — второй способ наиболее безопасен и предпочтителен.
Чтобы проще запомнить назначение ключей, их можно представить, как замок (открытый) и ключ к замку (закрытый). Замок без ключа не открыть, но при этом замок может видеть кто угодно.
Данные ключи являются взаимозависимыми: зашифровав информацию одним ключом, расшифровать ее можно только другим. Например, если вы зашифровали pdf-документ публичным ключом (ставите на него замок), то открыть и прочитать его сможете только вы, т. к. только у вас есть закрытый ключ. Так же это работает и в обратную сторону: если вы зашифруете письмо приватным ключом, то расшифровать его можно только вашим публичным ключом.
Это также означает, что так как ваш публичный ключ может распространяться открыто, то любой, кто им обладает (коллега), сможет открыть зашифрованный документ. Но в этом нет опасности, т. к. это лишь гарантирует, что документ был зашифрован именно вами. По такому принципу работает цифровая подпись.
Для создания ключей необходимо использовать утилиту ssh-keygen, поставляемую в Windows с Git. В Linux/macOS она входит в состав пакета SSH.

> ssh-keygen
После ввода данной команды все время жмите Enter, ничего не вводя.
В итоге в Windows по адресу C:\Users\Имя_пользователя\.ssh будет создано два файла: id_rsa (приватный ключ — никому его не показывайте) и id_rsa.pub (открытый ключ — можете показывать кому угодно).
Для Linux/macOS ключи будут созданы по адресу
/home/Имя_пользователя/.ssh
Откройте файл с открытым ключом обычным текстовым редактором и скопируйте его содержимое. Скопированный ключ необходимо добавить в GitHub, выполнив следующие шаги:

7. Настройка Git

7.1. Диспетчер учетных данных

В Windows Git для хранения данных пользователей поставляется с диспетчером учетных данных (Git Credential Manager for Windows, GCM). Мы с ним встречались во время установки Git. Он хранит учетные данные пользователей, что позволяет не вводить их все время при использовании авторизации через HTTPS.
Для активации его использования и отображения настройки введите в консоли:

> git config --global credential.helper manager
> git config credential.helper
Существуют и другие режимы хранения данных пользователей, отличные от manager.

7.2. Установка личной информации

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

git config --global user.email ВАШ_ЕМЭЙЛ
git config --global user.name ВАШЕ_ИМЯ
Параметр --global позволяет выставить один раз нужные настройки, которые Git будет использовать для всех репозиториев на вашем компьютере.
Отобразим внесенные изменения:

> git config --get user.name & git config --get user.email
ВАШЕ_ИМЯ
ВАШ_ЕМЭЙЛ
Если для каких-то отдельных репозиториев необходимо указать другое имя или электронную почту, то вместо --global используйте --local. При установке локальных настроек требуется, чтобы консоль была открыта в папке репозитория, а иначе команда не сработает.

7.3. Установка текстового редактора

Если вам требуется изменить текстовый редактор, который будет запускать Git при необходимости, то для начала нужно найти его расположение на вашем диске. В официальной документации к Git есть таблица с подсказками по поводу места размещения и параметров для разных редакторов. Либо вы можете найти его самостоятельно с помощью команды where, которую мы использовали во второй части.
Для смены редактора (хоть мы его и указали во время установки, но нам требуется внести для него дополнительную настройку) и отображения результата выполните команды:

> git config --global core.editor "'C:\Program Files\Sublime Text\sublime_text.exe\' --wait"

> git config --get core.editor
'C:\Program Files\Sublime Text\sublime_text.exe' --wait
Обратите внимание, что я добавил дополнительные одинарные кавычки (апострофы) в путь до текстового редактора (помимо двойных кавычек). Это сделано из-за наличия в пути пробелов (если у вас их нет, то и кавычки не нужны). Без дополнительных кавычек редактор не запустится.
Также я добавил параметр --wait, который не позволит закрыться редактору, пока вы его сами не завершите. Без него в будущем возникла бы ошибка «aborting commit due to empty commit message» при использовании команды commit (ее мы пройдем в следующей статье).

7.4. Смена имени ветки по умолчанию

Если по какой-то причине вам захочется поменять слово master (название ветки по умолчанию) на что-то другое, например, сейчас идет тренд в пользу main, то выполните команду:

git config --global init.defaultBranch main

7.5. Создание локального репозитория

Перед использованием Git необходимо создать локальный репозиторий и выполнить настройку.
Внешний репозиторий мы уже создали на GitHub, но он пока пуст.
Укажем Git на корневую папку нашего проекта, чтобы он мог отслеживать в ней все изменения.
Для этого существует команда init, отвечающая за создание репозитория, т. е. места на компьютере, где хранятся файлы и папки проекта.
Разместите репозиторий в папке StartJava. Именно в ней мы будем хранить все подпапки и классы, связанные с изучаемыми темами.
Откройте cmder в папке StartJava и введите git init:

D:\Java\StartJava
> git init
Initialized empty Git repository in D:/Java/StartJava/.git/
Просто init мы не можем написать, т. к. будет непонятно к чему относится данная команда. Поэтому необходимо в начале писать git, а только потом нужную команду.
Репозиторий успешно создан. В результате в консоли стало отображаться слово master, а в папке StartJava появилась скрытая папка .git (с точкой в начале), где и будет в дальнейшем храниться информация обо всех изменениях, сделанных в репозитории. Отобразим его содержимое:

D:\Java\StartJava (master)
> ls -a
./  ../  .git/  about.txt  src/

7.6. Корректное отображение русских букв

Если в Git некорректно отображается кириллица, то необходимо выполнить команду:

git config --global core.quotepath off
Я переименовал src в срс и выполнил git status (ее мы пройдем в следующей статье). Вместо срс отобразилось "\321\201\321\200\321\201/".
После выполнения настройки, русский текст будет отображаться корректно.
Дополнительную информацию про настройку Git можно посмотреть по ссылке.

7.7. Файлы настроек Git

В Git существуют аж целых три файла для хранения настроек. Чтобы понять зачем столько и что это за настройки, давайте отобразим их содержимое. Сильно вдаваться в подробности мы не будем, но для общего понимания этот вопрос стоит разобрать.
Введем команду git config -l --show-origin. При этом консоль должна быть открыта в корне проекта — в папке StartJava:

// 1 - системные настройки
file:C:/Program Files/Git/etc/gitconfig diff.astextplain.textconv=astextplain
file:C:/Program Files/Git/etc/gitconfig filter.lfs.clean=git-lfs clean -- %f
file:C:/Program Files/Git/etc/gitconfig filter.lfs.smudge=git-lfs smudge -- %f
file:C:/Program Files/Git/etc/gitconfig filter.lfs.process=git-lfs filter-process
file:C:/Program Files/Git/etc/gitconfig filter.lfs.required=true
file:C:/Program Files/Git/etc/gitconfig http.sslbackend=openssl
file:C:/Program Files/Git/etc/gitconfig http.sslcainfo=C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt 
file:C:/Program Files/Git/etc/gitconfig core.autocrlf=true
file:C:/Program Files/Git/etc/gitconfig core.fscache=true
file:C:/Program Files/Git/etc/gitconfig core.symlinks=false
file:C:/Program Files/Git/etc/gitconfig core.editor="C:\\Program Files\\Sublime Text\\sublime_text.exe"
file:C:/Program Files/Git/etc/gitconfig pull.rebase=false
file:C:/Program Files/Git/etc/gitconfig credential.helper=manager
file:C:/Program Files/Git/etc/gitconfig credential.https://dev.azure.com.usehttppath=true
file:C:/Program Files/Git/etc/gitconfig init.defaultbranch=master

// 2 - глобальные настройки
file:C:/Users/idesp/.gitconfig  user.email=ВАШ_ЕМЭЙЛ
file:C:/Users/idesp/.gitconfig  user.name=ВАШЕ_ИМЯ
file:C:/Users/idesp/.gitconfig  core.editor='C:\Program Files\Sublime Text\sublime_text.exe\' --wait
file:C:/Users/idesp/.gitconfig  core.quotepath=off

// 3 - локальные настройки
file:.git/config        core.repositoryformatversion=0
file:.git/config        core.filemode=false
file:.git/config        core.bare=false
file:.git/config        core.logallrefupdates=true
file:.git/config        core.symlinks=false
file:.git/config        core.ignorecase=true
Выведенную в терминале информацию я разбил на три части (по количеству файлов):
1
Системные настройки содержат общие для всех пользователей и их репозиториев значения (не забываем, что учетных записей пользователей в системе может быть больше одной)
2
Глобальные настройки содержат значения для одного конкретного пользователя и всех его репозиториев.
3
Локальные настройки хранят значения конкретного репозитория
Запомнить, какой файл с настройками когда использовать, несложно:
  • Если в вашей системе один пользователь, то системные настройки вам ни к чему
  • Если вы планируете для всех своих репозиториев использовать одни и те же параметры, то подойдут глобальные настройки
  • Если для какого-то репозитория необходимо установить свои параметры, отличные от других, то используйте локальные настройки
Исходя из всего выше сказанного, нам подходят глобальные настройки. Если нужно будет в будущем внести какие-то отличные от глобальных настроек параметры, то вы всегда сможете воспользоваться локальными настройками.

8. Установка Octotree

Для удобной навигации по файлам на GitHub установим расширение для браузера — Octotree: перейдите на сайт и выберите версию под используемый вами браузер.
Откроется магазин с расширениями для установки Octotree.
После установки плагина на GitHub с левой стороны появится боковая панель с отображением всех файлов и папок, которые есть в текущем репозитории. Выглядеть это может примерно так:
Это расширение поможет значительно упростить навигацию по файлам и папкам, которые будут представлены в виде дерева, как это обычно бывает в файловых системах.
Вместо Octotree, для навигации по файлам, вы можете использовать встроенную в GitHub боковую панель, которая отобразится как только в вашем удаленном репозитории появится и будет открыт хотя бы один файл.

Заключение

В этой вводной статье мы рассмотрели основы СКВ, их виды, а также создали аккаунт на GitHub и выполнили установку и настройку Git. В следующей публикации мы подробно рассмотрим основные команды Git, которые позволят вам начать с ней работать.
Ниже в таблице перечислены ключевые команды статьи.
Автор: Чимаев Максим
Оцените статью, если она вам понравилась!