SL Данная статья основана, на git-scm — он рекомендуется при желании более подробно изучить git
Git — Это самая популярная (на самом деле единственная) система контроля версий.
Что такое система контроля версий? Это система что позволяет контролировать версии файлов.
Допустим что у тебя есть проект что состоит из нескольких файлов — не важно что это: исходный код программы, книга, коллекция мемасов
Во время разработки будут происходить изменения в файлах, и тебе захочется зафиксировать их. Например сохранить весь проект в ZIP архив и положить его куда-нибудь на диск. На всякий случай.
Несмотря на простоту данного подхода, у него есть некоторые недостатки
Git
В большинстве случаев для контроля статуса проекта необходим специальный инструмент. Это Git. Его основные задачи:
- Хранение данных (репозитория) на удаленном сервере
- Облегчение доступа к данным через этот сервер
- Сохранение всех версий и вариантов проекта
- Записываются только изменения от оригинала — это уменьшает занимаемое места по сравнению с «вариантом с ZIP-папками»
- Сохранение дополнительной истории жизни проекта
- Облегченная отмена изменений какой-либо из версий
- Предоставление информации о разнице между версиями
- Упрощенное слияние нескольких вариантов проекта в один — например, слияние модификаций нескольких разработчиков
- Наличие децентрализованного бэкапа
Git предоставляет массу удобств, особенно если над проектом работает больше одного человека.
Консоль…
Нужно учитывать что git — это исключительно консольный инструмент. Есть различные дополнительные инструменты визуализации, но они поддерживают не все команды git. Наибольший функционал предоставляется именно из консоли. Некоторые варианты работы с git:
- Использовать консоль — самый функциональный и стандартизованный подход, но наименее интуитивный
- Плагины для редакторов. К примеру, VSCode вместе с плагином GitLens является весьма удобным инструментом
- Специализированные GUI для git — наиболее редкий и экзотичный вариант, различаются как функционалом так и уровнем поддержки.
В руководстве будет произведена работа именно с консольным вариантом (ввиду его стандартности). Если ты используешь другой интерфейс, то наверное это можно сделать как-то и через него (а может быть и нет)
Локальный репозиторий
— Это та папка в которой ты ведешь работу. Существует два способа создания:
- Превращение обычной папки проекта в git репозиторий. Для этого необходимо открыть консоль в папке проекта и выполнить
git init(не забудь сделать ZIP копию на всякий случай) - Выкачивание удаленного репозитория по ссылке при помощи
git clone <URL>— создаст новую папку и скачает туда проект с сервера
Локальный репозиторий будет иметь папку .git — её не стоит трогать. В ней содержится информация необходимая для корректной работы git
Удаленный репозиторий
Это дополнительные хранилища данных. Некоторые варианты:
- Публичный или приватный репозиторий на сайте github/gitlab
- Репозиторий на личном сервере команды или организации
- Также это может быть дополнительный репозиторий на той-же машине
Выкачивание данных из удаленного репозитория в локальный производится при помощи git fetch, а загрузка из локального в удаленный при помощи git push. Об этом позже.
Для начала стоит научится работать чисто в локальном репозитории.
Авторизация и контроль доступа
Для безопасной авторизации используются SSH ключи. В сервер необходимо загрузить публичный SSH ключ твоей машины. Но для этого необходимо их сгенерировать. Открываем консоль и вводим:
ssh-keygenНа запросы дополнительного ввода можно просто жать Enter, сейчас это не важно. После генерации получаем:
Your identification has been saved in C:\Users\Username/.ssh/id_rsa.
Your public key has been saved in C:\Users\Username/.ssh/id_rsa.pub.Здесь мы видим что сгенерировалось два файла:
id_rsa.pub— публичный ключ. Это замок что можно отдать серверу и сказать «Хэй, используй этот механизм для авторизации, я смогу его открыть»id_rsa— приватный ключ. Это уже именно настоящий секретный ключ. Используя его можно получить доступ к серверам на которых установлен публичный ключ. Думаю не стоит напоминать что для сохранения безопасности приватные ключи не передаются (ты ведь ключи от дома не раскидываешь где попало, верно?)
Теперь мы заходим в аккаунт нашего хранилища и передаем ему публичный ключ.
TBD
Теперь сервер будет знать наше устройство
Если один разработчик использует несколько компьютеров, то нужно сгенерировать для каждого из них свои ключи и загрузить несколько публичных ключей на сервер
Что ты такое?
Для того чтобы различать авторов необходимо сказать git кто ты. Эта информация не связана с авторизацией (уровнем доступа)
Зайдя в локальный репозиторий (что скачан git clone или создан git init) Вводим команды:
git config --global user.name "User Name"
git config --global user.email "mail@some.domain"Тонкости что стоит учитывать:
- Без этой конфигурации будет невозможно создавать коммиты (о них позже)
- Указанные имя и почта будут добавлены к коммитам как автор изменений
- Если использовать
--globalто эти настройки будут использованы по умолчанию для всех локальных репозиториев пользователя системы. Иначе задаются настройки для конкретного репозитория. Рекомендуется использовать--global - Эти строчки — просто ярлыки. Они никак не проверяются
- Да, ты можешь указать чужое имя и почту
- Да, это никак не проверяется программой
Ешё раз, это просто записка о том кто внес изменения. Если ты можешь их создать, ты можешь написать что угодно
Это не баг, это фича — ты действительно можешь выдавать себя за другого разработчика
Это сделано для того чтобы можно было «передавать» коммиты — разработчику отправили файл с патчем, он сделал config под автора, указал его почту и имя, и внес в репозиторий со своего аккаунта.
Обычно злоупотребления этим функционалом не происходит, поскольку ведущий разработчик и хост репозитория заметят аномалию
Если риск самозванцев это проблема, то можно использовать коммиты с цифровой подписью, что невозможно подделать. Но это на практике это не используется
Закончили с настройкой, держись, это была только первая страница.
