This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Небольшой мануал по работе с удаленным репозиторием
До этого момента мы работали только с локальным репозиторием, который располагается только на вашей машине.
При командной разработке необходимо как-то синхронизировать изменения в проекте всей команде, т.е. если один разработчик внес правки, должна быть возможность сделать так, чтобы эта правка появилась у всех остальных членов команды.
Для этих целей существует множество сервисов(github, gitlab, gitverse, etc). Мы будем в дальнейшем работать в моём собственном git сервере по адресу git.tias-dev.tech.
После входа важно создать ssh-ключ, который будет использоваться для идентификации вас, когда вы будете делать запросы к git серверу.
Создание ssh ключа
В терминале вводим
ssh-keygen
После будет несколько запросов на уточнение директории с ключами и задание пароля, можно просто везде нажимать Enter, в этом случае будут использованы директория по умолчанию и пустой пароль. В конце вы получите примерно вот такой вывод:
raison@raison - Nitro :~ $ ssh - keygen
Generating public / private ed25519 key pair .
Enter file in which to save the key (/ home / raison /. ssh / id_ed25519 ):
Enter passphrase ( empty for no passphrase ):
Enter same passphrase again :
Your identification has been saved in ./ temp / key
Your public key has been saved in ./ temp / key . pub
The key fingerprint is :
SHA256 : WsvRO72e /3 htxt3aD1QX71692JcDxkbKyFqTvw9cFAE raison@raison - Ni
The key ' s randomart image is :
+ - -[ ED25519 256] - -+
ascii картинка
+ - - - -[ SHA256 ] - - - - -+
В директории ~/.ssh (если вы использовали директорию по умолчанию) появяться 2 файла id_ed*.pub и id_ed*. Публичный и приватный ключи.
Собственно приватный ключ всегда лежит у вас и вы его не трогаете, а публичный надо будет закинуть на сайт:
- Справа сверху кликаем на квадратик с профилем;
Settings;gpg/ssh keys;- справа сверху
add key; - В поле
Contentвставляете содержимое публичного ключа; - Если всё ок, название ключа подставится автоматом.
Подтверждаем и готово. Если все прошло хорошо – у вас в списке должен появится добавленный ключ.
Теперь все ваши запросы на удаленный репозиторий будут подписаны вашей цифровой подписью. Ну и соединение будет шифроваться.
Важно! Данный ключ привязан именно к операционной системе. Поэтому если у вас есть несколько машин/операционных систем, то для доступа с них к вашему аккаунту надо с каждой из них сделать свой ssh-ключ и подключить их к вашему аккаунту.
Теперь про наш с вами pipeline работы.
Скачивание репозитория
На главной странице есть ссылка https/ssh. Нам надо выбрать ssh вариант и скопировать её. Далее в терминале запускаем:
git clone <скопированная ссылка>
Если всё пройдет хорошо, то появится подпапка с названием репозитория MaiLabs_2026-2027. Войдя в неё вы окажетесь в репозитории и сможете запускать git команды.
Указание на сервер
В общем случае вы можете на своём локальном репозитории работать сразу с несколькими удалёнными. Поэтому при некоторых командах надо указывать удалённый репозиторий, с которым вы хотите взаимодействовать(git pull, git push, например). Это можно делать по ссылкам на репозиторий, но гораздо удобнее использовать алиасы.
Посмотреть инфу про удалённые репозитории, подключённые к вашему локальному репозиторию можно командой git remote -v.
Получим примерно следующий вывод:
origin ssh://forgejo@git.tias-dev.tech/OpenCode/MaiLabs_2026-2027.git (fetch)
origin ssh://forgejo@git.tias-dev.tech/OpenCode/MaiLabs_2026-2027.git (push)
Слева алиас(по умолчанию origin), дальше ссылка, дальше действие для которого она используется: fetch -- скачать изменения, push -- отправить изменения.
Ветки серверного git'а
При подключенном git сервере у вас есть ваши ветки, которые лежат в вашем локальном репозитории (команда git branch обычно выводит только их) и есть серверные ветки, т.е. ветки, которые хранились на сервере и скачались вам.
Серверные ветки можно посмотреть командой git branch -a. Серверные ветки будут начинаться с префикса origin/.
Синхронизация веток
Когда вы скачиваете репозиторий, обычно скачиваются все ветки из сервера. Т.е. ваши локальные ветки будут уже синхронизированные(ветка abc совпадает с origin/abc).
Когда вы вносите изменения и создаёте коммиты -- меняются только ваши локальные ветки. Сервер об этих изменениях не знает. И если вы введете git status, то увидите сообщение типа
local branch abs is ahead of remote branch origin/abc by n commits
Собственно, чтобы синхронизировать ветки, вам надо отправить ваши коммиты в удалённый репозиторий.
Для этого используется команда
git push origin abc
где abc -- название ветки, которую вы хотите отправить.
Второй вариант рассинхрона -- это когда кто-то другой запушил изменения в вашу ветку на сервере и серверная ветка обогнала вашу ветку.
В этом случае, для того чтобы синхронизировать ветки надо
- Скачать информацию о ветке сервера
- Обновить свою ветку с серверной
Первый шаг делается командой
git fetch origin abc
где abc -- это название ветки, которую вы хотите скачать. Ветка скачается и ветка origin/abc в вашем локальном репозитории синхронизируется с оной веткой из сервера.
Дальше надо синхронизировать вашу ветку abc с origin/abc уже в пределах репозитория на вашей машине.
Для этого есть 2 варианта: merge(слияние) и rebase(смещение базы)
-
git merge origin/abc вливает ветку
origin/abcв вашу текущую ветку. Т.е. в вашей ветке создается новый коммит, который содержит все влитые изменения изorigin/abc -
git rebase origin/abc "перемещает" основу вашей ветки (т.е. то место, откуда она ответвляется от родительской ветки) на конец ветки
origin/abc. Получается, что ваша ветка теперь начинается из концаorigin/abcrebase меняет историю ветки, поэтому его не получится использовать в серверах с защитой веткок (как это сделано у нас). Тем не менее, у него есть несомненный плюс в том, что не создается промежуточных коммитов