💾 Archived View for pub.phreedom.club › ~kornilovnet › glog › 20230305-git.gmi captured on 2023-04-26 at 13:32:15. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-03-20)
-=-=-=-=-=-=-
🔨 Сведения для практического использования
Дата публикации: 2023-03-05 (редакция 2023-03-18)
Автор: @kornilov.net@pub.phreedom.club
Лицензия: GNU Free Documentation License 1.3
Статья не преследует цели обучения работе с Git, многочисленные возможности и настройки которой доступно изложены в обширной документации и сотнях разной степени глубины и полезности мануалов :) Она скорее "для себя на память" и поиграться с [text/gemini].
Передавать и забирать файлы капсулы просто и понятно с помощью [scp]. Но иногда в голове возникает путаница с версиями файлов. Начал на стационаре, продолжил на ноутбуке, потом в другую локацию перебрался … Ну, вы поняли. Можно использовать облако, а можно воспользоваться Git — распределённой системой управления версиями файлов. Благо пользователи хостинга [pub.phreedom.club] получают его "из коробки":
git --version git version 2.30.2
Страницы капсулы живут в каталоге [~/public_gemini] сервера. Если в этом каталоге вдруг присутствует внутренняя ссылка [public_gemini], принадлежащая [root:root], надо попросить Толстоевского ее удалить :) Но в любом случае, в каталоге нашего проекта уже существуют некие файлы, поэтому отделаться одной командой clone не выйдет:
git clone git@git.phreedom.club:<...> . fatal: destination path '.' already exists and is not an empty directory.
Есть несколько вариантов дальнейших действий, мне очевиднее следующий.
Выбираем любой (их прямо очень много) веб-хостинг git-проектов для создания удалённого репозитория. При выборе учитываем, что:
Правозащитная организация Software Freedom Conservancy (SFC), предоставляющая юридическую защиту свободным проектам и отстаивающая необходимость соблюдения лицензии GPL, объявила о прекращении любого использования платформы для совместной разработки кода GitHub и призвала разработчиков других открытых проектов последовать своему примеру.
Клубный ресурс git.phreedom.club ✓
Некоммерческая платформа codeberg.org ✓
Регистрируемся на выбранном хостинге. Создаем новый пустой репозиторий (не инициализируем его). На любом хосте генерируем пару SSH-ключей, содержимое публичного ключа копируем в настройки профиля хостинга. Теперь у нас есть, собственно, сам удалённый репозиторий, его адрес для подключения по SSH вида: [git@git.phreedom.club:... ], а также имя пользователя и приватный SSH-ключ для аутентификации. Идём дальше.
Добавляем в систему приватный SSH-ключ авторизации. Переходим в каталог с файлами нашей капсулы [~/public_gemini] и инициализируем его:
git init
Конфигурируем настройки [git] (будут дефолтно применяться для всех проектов текущего пользователя):
git config --global user.name name git config --global user.email email@domen.com
Во избежание сюрпризов явно указываем свой любимый редактор и ветку по умолчанию:
git config --global core.editor nano git config --global init.defaultBranch main
Указываем метод синхронизации коммитов (снимает простынь предупреждений команды [pull] при принятии изменений):
git config --global pull.ff only
Подробнее о методах синхронизации ✓
Проверяем настройки текущего проекта (приоритетные внизу):
git config --list
Добавляем свой адрес удалённого репозитория для подключения по SSH:
git remote add origin git@git.phreedom.club:...
Создаем файл [.gitignore] с исключениями, например:
echo public_gemini > .gitignore
Добавляем все файлы проекта в систему контроля версий:
git add .
Делаем первый коммит:
git commit -m "Привет, удалённый репозиторий!"
Отправляем файлы своего проекта в удалённый репозиторий:
git push origin main
Теперь копия всех файлов капсулы (кроме явно исключенных) находится в удалённом репозитории.
Добавляем в систему приватный SSH-ключ авторизации. Переходим в произвольный каталог DIR и клонируем свой удалённый репозиторий:
git clone git@git.phreedom.club:...
Это создаст в каталоге DIR уже инициированный подкаталог проекта со всеми файлами из удалённого репозитория. Переходим в этот подкаталог и дальше всегда работаем в нем. Конфигурируем настройки [git] по аналогии с сервером (см. выше). Опять же создаём файл [.gitignore] (например, macOS генерит свои служебные файлы [.DS_Store] с параметрами каталогов, которые нам здесь не нужны). Теперь актуальная копия всех файлов из удалённого репозитория (кроме явно исключенных) находится на хосте.
Создаём или изменяем на хосте какой-то файл проекта. Переходим в каталог проекта и выполняем:
git add .
Добавляем новый комментарий:
git commit -m "Добавлена инструкция по эксплуатации пылесоса"
Отправляем файл в удалённый репозиторий:
git push origin main
Теперь копия нашего вновь созданного (или изменённого) локального файла, над которым ещё надо поработать, находится в удалённом репозитории. Можно идти домой (или на работу).
Переходим в каталог проекта и выполняем:
git pull origin main
Теперь актуальное содержимое удалённого репозитория, включая тот самый "сырой" файл, есть и на этом хосте, можно его доработать.
Заходим на сервер, переходим в каталог [~/public_gemini] и выполняем:
git pull origin main
При наличии на хосте алиаса для подключения по SSH:
ssh ALIAS 'cd ~/public_gemini && git pull origin main'
Теперь копия нашего доработанного файла отправлена на сервер (т.е. опубликована в капсуле).
∎