Импорт репозитория git

Мердж-коммит в PhpStorm

PhpStorm помогает избавиться от мердж-коммитов через меньшее количество действий.
Если мы запушим локальные коммиты и получим rejected из-за того, что на сервере есть новые коммиты, то PhpStorm выдаст предупреждение, где предложит выбрать вариант:
как подтянуть новые коммиты, с мерждем или ребейзом.
Жмите кнопку «Rebase», мердж-коммита не будет и при этом локальный коммит сразу запушится на сервер.

Внимание

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

Что могу посоветовать

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

Но при работе в команде имеет смысл подумать над такими вещами:

• пушить коммиты почаще, чтобы коллеги быстрее получали доступ к новым изменениям
• пулиться почаще — обратная ситуация, почаще получать свежие изменения
• всегда пультесь с флажком ребейза — git pull —rebase origin master
• не удивляйтесь, что при пуллах и пушах могут возникать подобные ситуации, как мы рассматривали выше
• не стесняйтесь спрашивать коллег, если увидели незнакомую ситуацию
• больше практикуйтесь. Посадите домашний проект на git и работайте с ним

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

В следующем уроке мы узнаем, что такое ветки и будем активно работать с ними.
Там мы будем активно использовать git push и git pull, и это поможет закрепить уже пройденный материал.

Спасибо за внимание и до встречи!

Следующий урок ⇨
Урок 7. Ветки — главная фишка git

⇦ Предыдущий урок
Урок 5. История коммитов, git log

C помощью утилиты debmirror

Установка пакета:

# apt-get install debmirror

Создание каталога /mnt/repo/debian, в нём будет создаваться локальный репозиторий пакетов. Желательно чтобы это был примонтированный логический раздел жёсткого диска, чтобы в случае переустановки дистрибутива с нуля, при форматировании корневого раздела (/), не лишиться репозитория совсем.

# mkdir /mnt/repo/debian

Опции

-a	тип архитектуры (i386, amd64 и т.п.)
-d	ветка дистрибутива (stable, testing, unstable)
—nosource	не закачивать пакеты с исходным кодом
—i18n	закачивать файлы переводов описаний пакетов
-h	адрес сетевого репозитория
—method	тип протокола передачи файлов (ftp, http, rsync)
—progress	показывать подробности загрузки
/mnt/repo/	каталог, в котором будет создан ваш локальный репозиторий
-v	показывать, что сейчас происходит
—nosource	не скачивать исходные коды
-s main,contrib,non-free	секции, которые нужно скачать
—ignore-release-gpg	игнорировать проверку gpg-ключа
—ignore-missing-release	не прерывается, если нету файла Release

По умолчанию debmirror создаёт зеркало из секций main, contrib, non-free, main/debian-installer.

Можно исключать секции ненужных вам пакетов:

--exclude-deb-section="games" - не будет зеркалировать все игры.

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

Принадлежность к определенной секции вашего пакета можно узнать по команде:

$ apt-cache show имя_пакета

Пример получения бинарного зеркала (без пакетов с исходным кодом) Debian Stable для amd64:

# debmirror --host=ftp.fi.debian.org/debian --dist=stable --arch=amd64 --method=ftp --ignore-release-gpg --nosource /mnt/repo/debian

Непустой проект

Допустим, у нас на локальной машине уже есть проект second-site. Создаем в github репозиторий second-site. Заходим в папку проекта и выполняем команды

Все, можно приступать к работе над проектом. Команды add, commit и push мы разберем в следующих уроках.

Это единственный урок, в котором мы разбирались с тонкостями репозиториев. В дальнейшем будем считать, что репозиторий = проект.

Что могу посоветовать

github или bitbucket? Для личных проектов неважно, оба сервиса разрешают бесплатно создавать приватные репозитории. Для open source или резюме — github
не увлекайтесь клонированием в папку со своим названием

Есть шанс запутаться, самому или коллегам
не путайте публичный и приватный ключи. Отдаем вовне только публичный ключ id_rsa.pub
при смене рабочей машины можно не генерировать ssh-ключи заново, а скопировать их со старой машины. Тогда не придется заново прописывать новые ключи на серверах

Немного подробнее о копировании ssh-ключей

Как скопировать ssh-ключи с одной машины на другую

Хочу немного затронуть эту тему отдельно. Генерировать ключ на новой машине не обязательно. Но нужно выполнить такие действия

• Скопировать id_rsa и id_rsa.pub со старой машины на новую
• Посмотреть права на файлы, возможно, ключи окажутся слишком «открытыми» для записи и потребуется сменить им права доступа — sudo chmod 700 ~/.ssh/*
• Выполнить команду ssh-add

Ссылки, которые могут пригодиться

• github — https://github.com/
• bitbucket — https://bitbucket.org/
• подробнее об ssh-ключах (en) — connecting-to-github-with-ssh

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

Спасибо за внимание и до встречи!

Следующий урок ⇨
Урок 3. Делаем первые изменения — git diff и git status

⇦ Предыдущий урок
Урок 1. Установка и базовая настройка git

Клонирование удаленного репозитория с GitHub

Если вы хотите внести свой вклад в существующий проект, размещенный на GitHub или аналогичном онлайн-сервисе git, вам нужно клонировать их репозиторий с удаленного сервера, такого как Github, GitLab и т. д. Например, удаленный репозиторий Apache POI (библиотека Java для чтения и записи в файлы Excel) размещается по адресу https://github.com/apache/poi

Определение слова Clone в контексте Git заключается в создании локальной копии удаленного репозитория. В этом случае удаленный репозиторий размещается по адресу https://github.com/apache/poi и мы клонируем его в нашей локальной системе.

Ниже приведены шаги для клонирования (загрузки и отслеживания изменений) этого репозитория.

Шаг 1: извлеките и скопируйте URL-адрес, как указано на рисунке ниже, репозитория Apache POI на GitHub. То есть, https://github.com/apache/poi.git.

Шаг 2: в Git CMD перейдите к папке для хранения всех репозиториев Git локально. То есть C:\Users\admin1\LocalGit в этом примере.

Шаг 3: создайте каталог RemoteCloneRepo для хранения исходного кода репозитория Apache POI локально с помощью команды mkdir RemoteCloneRepo.

Перейдите в этот недавно созданный каталог с помощью команды cd RemoteCloneRepo.

Шаг 4: чтобы клонировать репозиторий, введите команду git clone https://github.com/apache/poi.git

Шаг 5: клонирование репозитория зависит от его размера. Обычно это занимает некоторое время для большого хранилища. Вам придется подождать, пока все файлы будут проверены.

Теперь вы можете вносить изменения в репозиторий. Git будет их отслеживать.

Как избежать такого в дальнейшем?

В GitHub и GitLab есть функциональность под названием «защищённые ветки» (protected branches). Отметьте , , или какие ещё ветки важны для вас как защищённые и система не даст вам выстрелить себе в ногу. Если force push всё же понадобится, то защиту всегда можно на время снять. См

документацию: https://help.github.com/articles/defining-the-mergeability-of-pull-requests/

Создайте алиасы для команд, которые должны делать , чтобы обезопасить себя от ошибок по неосторожности:

Прекратите уже экспериментировать прямо в основной ветке! Команда — ваш друг.

Pro Tip: У команды также ещё очень хорошо сочетаются друг с другом ключи и , особенно, если вы отвлеклись от проекта на месяцок-другой. Попробуйте, если, конечно, вам всё ещё мало приключений…

Подмодули

Клонирование репозитория с подмодулями

При клонировании репозитория вам необходимо инициализировать и обновить подмодули:

Запуск данной команды эквивалентен запуску команды:

после обычного клонирования репозитория

Обновление подмодулей

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

Для получения состояния последнего коммита всех подмодулей необходимо выполнить
следующую команду:

или использовать аргументы по умолчанию команды git pull:

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

Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:

Добавление подмодулей

В текущий проект можно включить другой репозиторий Git в качестве папки, отслеживаемый Git:

После этого необходимо добавить и зафиксировать новый файл .gitmodules. В нём описано
какие подмодули следует клонировать при запуске команды git submodule update

Локальный репозиторий

Есть несколько способов создать локальный репозиторий Debian. Из того, что я пробовал, самым простым и удобным мне показался apt-mirror, но у него есть один баг, если его использовать как зеркало официальных репозиториев. Он не качает переводы в формате .gz и.xz, только .bz2. В итоге, когда будете использовать локальный репозиторий в качестве зеркала официального, получите ошибку:

File not found updates/main/i18n/Translation-en (2: No such file or directory)

Другой простой вариант — использовать reprepro. Я не буду подробно останавливаться на настройке локального репозитория для Debian, так как это отдельная тема. По хорошему, репозиторий надо подписать gpg ключом, опубликовать с помощью http или ftp, может еще как-то. Я только кратко покажу, как это делается, чтобы вы понимали, что это вообще такое. А если реально нужен будет локальный репозиторий, вы без проблем найдете его подробную настройку. Там нет ничего сложного.

Установим reprepro.

# apt install reprepro

Дальше создаем каталог для локального репозитория и конфиг.

# mkdir -p /mnt/repo/debian/conf
# touch /mnt/repo/debian/conf/distributions

Конфиг делаем примерно следующего содержания.

Codename:  bullseye
Suite:  stable
Version: 11.x
Origin: Debian
Label: Debian 11.x
Description: Debian Stable Updates Repository
Architectures: amd64 source
Components: main
DebIndices: Packages Release . .gz .bz2
DscIndices: Sources Release . .gz .bz2
Contents: . .gz .bz2

Выполняем инициализацию репозитория.

# cd /mnt/repo/debian
# reprepro export
# reprepro createsymlinks

Теперь можно добавлять пакеты в локальный репозиторий следующей командой.

# reprepro -b /mnt/repo/debian --ask-passphrase includedeb bullseye /home/package.deb

Для того, чтобы подключить локально новый репозиторий, его нужно добавить в sources.list.

deb  file:/mnt/repo/debian bullseye main

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

Создаём новую ветку и добавляем в проект внесённые изменения

Добавим к проекту пустой CSS-файл и подключим его к HTML. После этого в меню редактора появятся два цвета: HTML-файл подсветится оранжевым, а CSS-файл — зелёным. Оранжевый означает, что файл уже есть в удалённом репозитории и его нужно обновить. Зелёный — файла нет в репозитории. Переходим в GitHub Desktop и добавляем коммит для этого изменения.

Подсветка файлов в меню меняется после добавления или редактирования файлов — это подсказка, чтобы мы не забывали обновлять репозиторий

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

• Переходим в GitHub Desktop.
• Открываем раздел Current Branch, нажимаем кнопку New Branch, пишем название новой ветки и кликаем Create New Branch.
• Возвращаемся в редактор кода и тестируем идею.

После создания новой ветки не забудьте нажать на Push origin, чтобы изменения попали в удалённый репозиторий на сайте GitHub.

Создаём новую ветку в GitHub Desktop
Тестируем изменения, добавленные в новую ветку. Основная ветка в этот момент находится в прежнем состоянии и сохраняет свой код

Предположим, наша идея с красным фоном оказалась удачной и код нужно залить в основную ветку. Чтобы это сделать, переходим сайт GitHub, нажимаем кнопку Сompare & pull request и подтверждаем изменения кнопкой Merge pull request. Последний шаг — переходим в GitHub Desktop, кликаем Fetch origin и синхронизируемся с удалённым репозиторием. Теперь код из дополнительной ветки попал в основную, а изменения есть на ПК и в облаке.

Список репозиториев в sources.list

Изначально, содержимое sources.list будет зависеть от того, какой источник для пакетов вы выбрали во время установки debian. К примеру, в моем случае для системы Debian 10 он выглядит следующим образом.

deb http://mirror.corbina.net/debian/ buster main
deb-src http://mirror.corbina.net/debian/ buster main

deb http://security.debian.org/debian-security buster/updates main
deb-src http://security.debian.org/debian-security buster/updates main

# buster-updates, previously known as 'volatile'
deb http://mirror.corbina.net/debian/ buster-updates main
deb-src http://mirror.corbina.net/debian/ buster-updates main

Для Debian 11 bullseye немного изменился формат записи для репозитория security. Теперь он выглядит так:

deb http://security.debian.org/ bullseye-security main

В общем случае файл sources.list имеет следующую структуру:

deb http://site.example.com/debian distribution component1 component2 component3
deb-src http://site.example.com/debian distribution component1 component2 component3

deb и deb-src	тип архива, бинарные пакеты (deb) или пакеты с исходным кодом (deb-src)
http://site.example.com/debian	url репозитория
distribution	псевдоним релиза (bullseye, buster, stretch и т.д.), либо класс релиза (stable, oldstable и т.д.)
component	main, contrib или non-free набор пакетов

Про псевдонимы релизов и наборы пакетов мы поговорим ниже более подробно в соответствующем разделе.

Помимо основного файла sources.list, репозитории могут располагаться в отдельных файлах в директории /etc/apt/sources.list.d. Формат файлов такой же, как и у основного. Обычно туда добавляют отдельно в каждый файл набор источников для какой-то определенной программы. Например, proxmox размещает в отдельном файле свой платный репозиторий.

# cat /etc/apt/sources.list.d/pve-enterprise.list
deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise

Архив репозиториев для старых версий

В официальном репозитории Debian располагаются пакеты для текущего релиза (stable), для прошлого релиза (oldstable) и для будущего релиза (testing). Для всех старых релизов репозитории отправляются в архив — http://archive.debian.org/debian/, который заморожен. Обновлений к релизам из архива больше нет. Но если вам по какой-то причине нужен репозиторий для старой версии Debian, вы можете им воспользоваться.

Ниже представляю готовые настройки репозиториев для прошлых версий.

Debian 9 stretch

Репозитории Debian 9 stretch пока еще находятся в основных репозиториях:

deb http://deb.debian.org/debian stretch main
deb-src http://deb.debian.org/debian stretch main

deb http://deb.debian.org/debian-security/ stretch/updates main
deb-src http://deb.debian.org/debian-security/ stretch/updates main

deb http://deb.debian.org/debian stretch/updates main
deb-src http://deb.debian.org/debian stretch/updates main

В скором времени они тоже переедут в архив. Случится это в июне 2022 года, когда кончится период длительной поддержки. Тогда их можно будет подключить по следующим адресам:

deb http://archive.debian.org/debian/ stretch main non-free contrib
deb-src http://archive.debian.org/debian/ stretch main non-free contrib
deb http://archive.debian.org/debian-security/ stretch/updates main contrib
deb-src http://archive.debian.org/debian-security/ stretch/updates main contrib

Debian 8 jessie

Репозитории Debian 8 jessie:

deb http://archive.debian.org/debian/ jessie main non-free contrib
deb-src http://archive.debian.org/debian/ jessie main non-free contrib
deb http://archive.debian.org/debian-security/ jessie/updates main contrib
deb-src http://archive.debian.org/debian-security/ jessie/updates main contrib

Debian 7 wheezy

Репозитории Debian 7 wheezy:

deb http://archive.debian.org/debian/ wheezy main non-free contrib
deb-src http://archive.debian.org/debian/ wheezy main non-free contrib
deb http://archive.debian.org/debian-security/ wheezy/updates main contrib
deb-src http://archive.debian.org/debian-security/ wheezy/updates main contrib

Debian 6 squeeze

Репозитории Debian 6 squeeze:

deb http://archive.debian.org/debian/ squeeze main non-free contrib
deb-src http://archive.debian.org/debian/ squeeze main non-free contrib
deb http://archive.debian.org/debian-security/ squeeze/updates main contrib
deb-src http://archive.debian.org/debian-security/ squeeze/updates main contrib

Защита репозиториев

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

В Ubuntu по умолчанию доверенными являются репозитории на установочных дисках и основные интернет репозитории — archive.ubuntu.com. При наличие на пользовательском компьютере нескольких подключенных репозиториев, предпочтение отдается доверенным.

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

sudo apt-key add repo.key

Где — полученный вами ключ репозитория.

Или при помощи графического интерфейса — запустите «Источники приложений» (Система→Администрирование→Источники приложений), перейдите на вкладку «Аутентификация» и нажмите на кнопку «Импортировать файл ключа…» — откроется диалог выбора файла. Выберите файл ключа и нажмите ОК.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 0x12345678

Где вместо keyserver.ubuntu.com можно подставить адрес другого сервера ключей, а вместо 12345678 необходимо написать идентификатор нужного вам ключа.

Совет: для того, чтобы разом попытаться импортировать все недостающие ключи репозиториев, выполните в консоли:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com `sudo aptitude update 2>&1 | grep -o '\{16\}$' | xargs`

Зеркало официального репозитория yandex mirror

В рунете популярен репозиторий Яндекса под названием Yandex.Mirror — https://mirror.yandex.ru. Это зеркало популярных дистрибутивов Linux, Freebsd и других проектов, в том числе и Debian. Работает по протоколам HTTP, FTP и rsync.

Зеркало Яндекс можно использовать как для обновления пакетов, так и загрузки iso образов. Образы последней стабильной версии Debian можно скачать отсюда — https://mirror.yandex.ru/debian-cd/current/amd64/. Для использования Yandex.Mirror в регулярных обновлениях Debian, приведите sources.list к следующему виду.

deb http://mirror.yandex.ru/debian bullseye main
deb-src http://mirror.yandex.ru/debian bullseye main

deb http://mirror.yandex.ru/debian bullseye-updates main
deb-src http://mirror.yandex.ru/debian bullseye-updates main

deb https://mirror.yandex.ru/debian-security bullseye-security main
deb-src https://mirror.yandex.ru/debian-security bullseye-security main

Repository yandex mirror можно так же использовать для сетевой установки систем.

Устройство репозитория

Пример записи в файле Packages для пакета :

Package: abiword
Priority: optional
Section: gnome
Installed-Size: 7808
Maintainer: Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: Masayuki Hatta (mhatta) <mhatta@debian.org>
Architecture: i386
Version: 2.6.6-0ubuntu1
Replaces: abiword-gnome
Provides: abiword-gnome
Depends: libaiksaurus-1.2-0c2a (>= 1.2.1+dev-0.12), libaiksaurusgtk-1.2-0c2a 
(>= 1.2.1+dev-0.12), libart-2.0-2 (>= 2.3.18), libatk1.0-0 (>= 1.20.0), libc6
(>= 2.7), libcairo2 (>= 1.2.4), libenchant1c2a (>= 1.4.2), libexpat1 (>= 1.95.8),
libfontconfig1 (>= 2.4.0), libfreetype6 (>= 2.3.5), libfribidi0 (>= 0.10.9),
libgcc1 (>= 1:4.1.1), libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.18.0),
libgnomecanvas2-0 (>= 2.11.1), libgnomeprint2.2-0 (>= 2.17.0), libgnomeprintui2.2-0
(>= 2.17.0), libgsf-1-114 (>= 1.14.11), libgtk2.0-0 (>= 2.15.0), libice6 (>= 1:1.0.0),
libidn11 (>= 0.5.18), libjpeg62, libloudmouth1-0 (>= 1.1.4-2), libncurses5 
(>= 5.6+20071006-3), libots0, libpango1.0-0 (>= 1.22.0), libpng12-0 (>= 1.2.13-4),
libpopt0 (>= 1.14), libreadline5 (>= 5.2), librsvg2-2 (>= 2.22.3), libsm6, 
libstdc++6 (>= 4.2.1), libwmf0.2-7 (>= 0.2.8.4), libwpd8c2a, libwpg-0.1-1, libwv-1.2-3 
(>= 1.2.4), libx11-6, libxft2 (>> 2.1.1), libxml2 (>= 2.6.27), zlib1g (>= 1:1.1.4), 
abiword-common (>= 2.6.6-0ubuntu1), gsfonts
Recommends: abiword-plugin-grammar, abiword-plugin-mathview, abiword-help, 
aspell-en | aspell-dictionary, poppler-utils
Suggests: abiword-plugin-goffice
Conflicts: abiword-gnome
Filename: pool/main/a/abiword/abiword_2.6.6-0ubuntu1_i386.deb
Size: 2969028
MD5sum: f70817557ecbf4183b498fd98051ec03
SHA1: 8c666220527fe78328b5f94fec93fd62eddd332f
SHA256: 47de1dcf28866a33c0e4baefadb2d29ff9046ba4e4ae6e600801e5e3a6ec40c7
Description: efficient, featureful word processor with collaboration
 AbiWord is a full-featured, efficient word processing application.
 It is suitable for a wide variety of word processing tasks, and
 is extensible with a variety of plugins.
 .
 This package includes many of the available import/export plugins allowing
 AbiWord to interact with ODT, WordPerfect, and other formats.  It also
 includes tools plugins, offering live collaboration with AbiWord users
 on Linux and Windows (using TCP or Jabber/XMPP), web translation and
 dictionary support, and more.
 .
 Additional plugins that require significant amounts of extra software to
 function are in the various abiword-plugin-* packages.
Homepage: http://www.abisource.com/
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu
Task: xubuntu-desktop

Файлов Packages.gz может быть несколько (например, по одному для каждой архитектуры). Файл Release содержит описание репозитория в целом и ссылки на различные Packages.gz

Общая же схема работы выглядит примерно так:

1. Пользовательский компьютер подключается к репозиторию, и при наличии защиты, проверяет его истинность (см. главу ).
2. Читает файл Release, находит и скачивает необходимые Packages.gz
3. На основе скачанных Packages.gz обновляет локальную базу данных пакетов.
4. Теперь пользовательский компьютер «знает» где находится тот или иной пакет и при необходимости легко может его скачать и установить.

Возможные ошибки

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

Репозиторий не содержит файла Release

Текст ошибки, по идее, дает готовый ответ. В репозитории нет обязательного файла Release. Но суть в том, что он скорее всего есть. Дело тут чаще всего в том, что вы добавили к себе репозиторий, который не содержит указанной вами ветки. К примеру, вы добавили репозиторий в дистрибутив Buster, а в репозитории нет поддержки этого дистрибутива. Предыдущие есть, а этого нет.

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

Создание пары ключей SSH

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

Настоятельно рекомендуется установить пароль на файлы ключей, поскольку это обеспечивает дополнительный  уровень безопасности. В операционных системах Windows есть отдельные инструменты для генерации пары ключей, например, PuTTY Gen. Но эта программа запрещена в некоторых странах, а потому она идет с оговоркой о необходимости согласовать ее использование с местным законодательством. Уточнив этот момент, можно войти на VPS, создать пару ключей, и скачать id_rsa и id_rsa.pub.

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