Перейти до вмісту

Noleron Git: відмінності між версіями

Матеріал з Noleron Wiki
Lesyk (обговорення | внесок)
Прибрано зайвий відступ перед плашкою
Lesyk (обговорення | внесок)
Переписано сторінку Git за правилами Noleron Wiki
 
Рядок 1: Рядок 1:
{{Стаття про сервіс Project Noleron}}
{{Стаття про сервіс Project Noleron}}


'''Noleron Git''' — Git-сервіс Noleron на базі [[Forgejo]].
'''Noleron Git''' — сервіс для зберігання Git-репозиторіїв, спільної роботи з кодом, керування проєктами та публікації вікі. Сервіс працює на базі [[Forgejo]] — вільної платформи для самостійного розміщення Git-репозиторіїв.


Ця сторінка пояснює, як налаштувати GPG-підпис комітів і додати відкритий ключ до облікового запису Forgejo.
== Можливості ==


__TOC__
* створення та зберігання Git-репозиторіїв;
* перегляд файлів, гілок, комітів і тегів;
* керування задачами та обговореннями;
* перегляд і подання змін через pull request;
* вікі для репозиторіїв;
* керування учасниками та правами доступу;
* підписування комітів за допомогою GPG;
* доступ до репозиторіїв через вебінтерфейс і Git-клієнти.


== Встановлення інструментів ==
Noleron Git підходить для особистих проєктів, командної розробки та публікації програмного коду.


=== Windows ===
== Початок роботи ==
Встановіть [https://gpg4win.org/ Gpg4win] і перевірте, що Git використовує потрібну версію GPG:


<pre>git config --global gpg.program "C:\Program Files (x86)\GnuPG\bin\gpg.exe"</pre>
# Відкрийте [https://git.noleron.com Noleron Git].
# Увійдіть до облікового запису або створіть його, якщо реєстрація доступна.
# Створіть новий репозиторій або відкрийте наявний.
# Скопіюйте адресу репозиторію для роботи через Git.
# Клонуйте репозиторій на локальний комп’ютер.


=== macOS ===
Приклад клонування репозиторію через HTTPS:


<pre>brew install gpg2 gnupg pinentry-mac
<pre>git clone https://git.noleron.com/КОРИСТУВАЧ/РЕПОЗИТОРІЙ.git</pre>
mkdir -p ~/.gnupg
echo "pinentry-program $(brew --prefix)/bin/pinentry-mac" >> ~/.gnupg/gpg-agent.conf
echo "use-agent" >> ~/.gnupg/gpg.conf
echo 'export GPG_TTY=$(tty)' >> ~/.bash_profile</pre>


Для Zsh використовуйте <code>~/.zprofile</code> замість <code>~/.bash_profile</code>.
Для доступу через SSH використовуйте адресу, яку показує сторінка відповідного репозиторію.


== Створення GPG-ключа ==
== Автентифікація та ключі ==


<pre>gpg --full-generate-key</pre>
Для роботи з Git можна використовувати HTTPS або SSH. Для підписування комітів використовується GPG.


Рекомендовані параметри:
Відкритий GPG-ключ можна додати до налаштувань профілю Forgejo. Секретний ключ не можна завантажувати до сервісу, репозиторію або передавати іншим людям.


* тип ключа: '''RSA and RSA''';
Приклад налаштування підписування комітів:
* розмір: '''4096''';
* термін дії: '''0''' — безстроковий ключ;
* ім’я та email: ті самі, що використовуються в Git;
* парольна фраза: довга й унікальна.


Перегляньте ключі та знайдіть свій ідентифікатор:
<pre>git config --global user.signingkey KEYID
git config --global commit.gpgsign true
git config --global gpg.program gpg</pre>
 
Замість <code>KEYID</code> використовуйте ідентифікатор власного GPG-ключа.
 
Перевірити список ключів можна командою:


<pre>gpg --list-secret-keys --keyid-format LONG</pre>
<pre>gpg --list-secret-keys --keyid-format LONG</pre>


У подальших командах замініть <code>KEYID</code> на свій ідентифікатор.
Щоб експортувати відкритий ключ:
 
Щоб експортувати '''відкритий''' ключ:


<pre>gpg --armor --export KEYID</pre>
<pre>gpg --armor --export KEYID</pre>


Секретний ключ нікому не передавайте.
До Forgejo потрібно додавати лише відкритий ключ.
 
== Імпорт наявного ключа ==
 
<pre>gpg --import my-key.asc
gpg --edit-key KEYID</pre>
 
У консолі GPG виконайте:
 
<pre>trust
5
quit</pre>
 
== Додавання ключа до Forgejo ==
 
# Експортуйте відкритий ключ командою <code>gpg --armor --export KEYID</code>.
# Відкрийте налаштування профілю у Forgejo.
# Перейдіть до розділу '''SSH / GPG Keys''' або відповідного розділу ключів.
# Додайте повний текст відкритого ключа.
# Переконайтеся, що email ключа збігається з email автора комітів.
 
== Налаштування Git ==
 
<pre>git config --global user.signingkey KEYID
git config --global commit.gpgsign true</pre>
 
Для одного коміту:
 
<pre>git commit -S -m "Підписаний коміт"</pre>
 
Перевірити підпис локально:


<pre>git log --show-signature -1
== Робота з репозиторієм ==
git verify-commit HEAD</pre>


== Кешування парольної фрази ==
Після клонування репозиторію можна створити гілку, внести зміни та надіслати їх на сервер:


=== Windows ===
<pre>git switch -c назва-гілки
У Kleopatra відкрийте '''Settings → Configure Kleopatra → GnuPG System → Private Keys''' і встановіть кешування PIN на <code>28800</code> секунд.
git add .
git commit -S -m "Опис змін"
git push -u origin назва-гілки</pre>


=== macOS ===
Перед публікацією змін перевірте:
Під час першого підпису дозвольте зберігання парольної фрази в системному Keychain, якщо довіряєте цьому комп’ютеру.


=== Ubuntu та інші Linux ===
* правильність назви репозиторію;
* список файлів, які будуть додані до коміту;
* відсутність паролів, токенів і приватних ключів;
* статус тестів і перевірок;
* підпис коміту, якщо він потрібен для проєкту.


<pre>mkdir -p ~/.gnupg
== Права доступу ==
echo "default-cache-ttl 28800" >> ~/.gnupg/gpg-agent.conf
gpgconf --reload gpg-agent</pre>


== Перевірка у Forgejo ==
Репозиторії можуть бути відкритими або приватними — залежно від налаштувань і політики проєкту.


Створіть тестовий підписаний коміт і відправте його до репозиторію. У Forgejo коміт має відображатися як '''Verified'''.
Передавання доступу іншому користувачу надає йому можливість переглядати або змінювати вміст відповідно до призначеної ролі. Не надавайте права адміністратора без необхідності.


Якщо підпис не перевіряється, перевірте:
== Безпека ==


* email у Git збігається з email GPG-ключа;
Ніколи не додавайте до Git-репозиторіїв:
* до Forgejo додано саме відкритий ключ;
* <code>user.signingkey</code> містить правильний <code>KEYID</code>;
* локально працює <code>gpg --verify</code>;
* дата й термін дії ключа актуальні.


== Безпека ключа ==
* паролі;
* API-ключі;
* токени доступу;
* секретні ключі SSH або GPG;
* файли <code>.env</code>;
* резервні копії з обліковими даними;
* приватні сертифікати;
* рядки підключення до баз даних.


* Зберігайте резервну копію секретного ключа офлайн.
Якщо секрет уже потрапив до коміту, простого видалення файлу недостатньо: значення потрібно відкликати або замінити, оскільки воно може залишитися в історії Git.
* За можливості використовуйте апаратний ключ, наприклад YubiKey.
* Не передавайте секретний ключ через email, чати або незашифровані файли.
* Не публікуйте парольну фразу.


== Додаткові матеріали ==
== Посилання ==


* [https://forgejo.org/docs/latest/user/signing-commits/ Forgejo: підпис комітів]
* [https://git.noleron.com Відкрити Noleron Git]
* [https://gnupg.org/documentation/ GnuPG: документація]
* [https://forgejo.org/ Офіційний сайт Forgejo]
* [https://www.yubico.com/products/security-key/ YubiKey]
* [https://forgejo.org/docs/latest/ Документація Forgejo]

Поточна версія на 16:10, 13 вересня 2026

NoleronЦя стаття описує сервіс Project Noleron.
Інформація на сторінці стосується призначення, можливостей або використання одного із сервісів Noleron.

Noleron Git — сервіс для зберігання Git-репозиторіїв, спільної роботи з кодом, керування проєктами та публікації вікі. Сервіс працює на базі Forgejo — вільної платформи для самостійного розміщення Git-репозиторіїв.

Можливості

[ред. | ред. код]
  • створення та зберігання Git-репозиторіїв;
  • перегляд файлів, гілок, комітів і тегів;
  • керування задачами та обговореннями;
  • перегляд і подання змін через pull request;
  • вікі для репозиторіїв;
  • керування учасниками та правами доступу;
  • підписування комітів за допомогою GPG;
  • доступ до репозиторіїв через вебінтерфейс і Git-клієнти.

Noleron Git підходить для особистих проєктів, командної розробки та публікації програмного коду.

Початок роботи

[ред. | ред. код]
  1. Відкрийте Noleron Git.
  2. Увійдіть до облікового запису або створіть його, якщо реєстрація доступна.
  3. Створіть новий репозиторій або відкрийте наявний.
  4. Скопіюйте адресу репозиторію для роботи через Git.
  5. Клонуйте репозиторій на локальний комп’ютер.

Приклад клонування репозиторію через HTTPS:

git clone https://git.noleron.com/КОРИСТУВАЧ/РЕПОЗИТОРІЙ.git

Для доступу через SSH використовуйте адресу, яку показує сторінка відповідного репозиторію.

Автентифікація та ключі

[ред. | ред. код]

Для роботи з Git можна використовувати HTTPS або SSH. Для підписування комітів використовується GPG.

Відкритий GPG-ключ можна додати до налаштувань профілю Forgejo. Секретний ключ не можна завантажувати до сервісу, репозиторію або передавати іншим людям.

Приклад налаштування підписування комітів:

git config --global user.signingkey KEYID
git config --global commit.gpgsign true
git config --global gpg.program gpg

Замість KEYID використовуйте ідентифікатор власного GPG-ключа.

Перевірити список ключів можна командою:

gpg --list-secret-keys --keyid-format LONG

Щоб експортувати відкритий ключ:

gpg --armor --export KEYID

До Forgejo потрібно додавати лише відкритий ключ.

Робота з репозиторієм

[ред. | ред. код]

Після клонування репозиторію можна створити гілку, внести зміни та надіслати їх на сервер:

git switch -c назва-гілки
git add .
git commit -S -m "Опис змін"
git push -u origin назва-гілки

Перед публікацією змін перевірте:

  • правильність назви репозиторію;
  • список файлів, які будуть додані до коміту;
  • відсутність паролів, токенів і приватних ключів;
  • статус тестів і перевірок;
  • підпис коміту, якщо він потрібен для проєкту.

Права доступу

[ред. | ред. код]

Репозиторії можуть бути відкритими або приватними — залежно від налаштувань і політики проєкту.

Передавання доступу іншому користувачу надає йому можливість переглядати або змінювати вміст відповідно до призначеної ролі. Не надавайте права адміністратора без необхідності.

Безпека

[ред. | ред. код]

Ніколи не додавайте до Git-репозиторіїв:

  • паролі;
  • API-ключі;
  • токени доступу;
  • секретні ключі SSH або GPG;
  • файли .env;
  • резервні копії з обліковими даними;
  • приватні сертифікати;
  • рядки підключення до баз даних.

Якщо секрет уже потрапив до коміту, простого видалення файлу недостатньо: значення потрібно відкликати або замінити, оскільки воно може залишитися в історії Git.

Посилання

[ред. | ред. код]