Как создать или обновить GitHub Personal Access Token для работы с приватным репозиторием

GitHub Personal Access Token (PAT) — это персональный токен доступа, который позволяет приложениям, серверам и системам автоматического развёртывания безопасно взаимодействовать с репозиториями GitHub без использования пароля от аккаунта.

Токены применяются для автоматического обновления сайтов, загрузки изменений в GitHub, работы с Git API и подключения сторонних инструментов.

В этой инструкции разберём, как создать новый Fine-grained Personal Access Token, правильно настроить его разрешения, заменить устаревший токен на сервере и устранить распространённые ошибки авторизации.

1. Для чего нужен GitHub Token

Предположим, у нас есть сайт example.com, исходный код которого хранится в приватном репозитории:

https://github.com/example-user/my-website

Сайт работает на Linux-сервере и использует Git для получения обновлений и отправки изменений.

Для выполнения команд git pull и git push через HTTPS необходима авторизация. Обычный пароль GitHub для этих операций больше не используется. Вместо него можно применять Personal Access Token.

Токен особенно полезен, если:

сайт автоматически обновляется из GitHub;
изменения файлов отправляются в репозиторий прямо с сервера;
CMS имеет встроенный модуль Git Deploy;
развёртывание выполняется через скрипты;
к приватному репозиторию подключаются сторонние приложения.

2. Fine-grained и Classic Token: в чём разница

GitHub поддерживает два типа персональных токенов.

Fine-grained Personal Access Token — более гибкий вариант, позволяющий ограничивать доступ конкретными репозиториями и отдельными разрешениями.

Personal Access Token (Classic) — старый формат, который использует более широкие группы разрешений (scopes).

Для большинства новых интеграций рекомендуется Fine-grained Token, если используемый инструмент его поддерживает.

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

3. Создание нового Fine-grained Personal Access Token

Перейдите на страницу:

https://github.com/settings/personal-access-tokens

Нажмите Generate new token.

Заполните настройки:

ПараметрПримерToken namewebsite-deployDescriptionДоступ сервера к GitHubResource ownerexample-userExpiration90 daysRepository accessOnly select repositoriesSelected repositoriesmy-website

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

Настройка разрешений

Откройте раздел Repository permissions.

Для разных задач потребуются разные права.

ЗадачаРазрешенияТолько скачивание обновленийContents: Read-onlyGit Pull из приватного репозиторияContents: Read-onlyGit Commit & PushContents: Read and writeИзменение GitHub Actions workflowContents: Read and write + Workflows: Read and write

Разрешение Metadata: Read-only обычно устанавливается автоматически.

Важно выдавать только те права, которые действительно необходимы приложению.

После настройки нажмите Generate token.

GitHub покажет созданный токен. Скопируйте его и сохраните в защищённом месте. Полное значение токена впоследствии может быть недоступно для повторного просмотра.

4. Как заменить токен на Linux-сервере

Допустим, исходный код сайта размещён в каталоге:

/var/www/example.com/public_html

Подключитесь к серверу по SSH.

Перейдите в каталог проекта:

cd /var/www/example.com/public_html

Проверьте подключение:

git remote -v

В нашем примере должен использоваться HTTPS-адрес репозитория:

https://github.com/example-user/my-website.git

Если используется SSH-адрес вида git@github.com:..., следует настраивать SSH-ключ, а не HTTPS-токен.

Для ручной проверки доступа выполните:

git fetch origin main

Когда Git запросит данные авторизации:

Username for 'https://github.com':

введите:

example-user

В поле Password вставьте Personal Access Token вместо пароля GitHub.

Если токен имеет правильные разрешения, Git получит доступ к репозиторию.

Безопасное сохранение токена

Для автоматической работы Git можно настроить отдельное хранилище учётных данных.

Например, для Linux-пользователя, под которым работает сайт, можно создать файл в его домашнем каталоге.

touch ~/.git-credentials
chmod 600 ~/.git-credentials

Чтобы не вводить токен прямо в истории команд, используйте скрытый ввод:

read -rsp "GitHub token: " GH_TOKEN
echo

После вставки нового токена запишите его в файл:

printf 'https://example-user:%s@github.com\n' "$GH_TOKEN" > ~/.git-credentials
chmod 600 ~/.git-credentials
unset GH_TOKEN

Подключите этот файл к репозиторию:

git config --local credential.helper \
  "store --file=$HOME/.git-credentials"

Теперь Git сможет использовать сохранённые учётные данные без интерактивного запроса.

Важно: Git Credential Store сохраняет токен в незашифрованном виде. Поэтому необходимы ограниченные права доступа к файлу, а предпочтительным решением для производственных систем является защищённое хранилище секретов или специальный credential manager. Файл нельзя размещать в публичном каталоге сайта.

Если CMS имеет собственный защищённый механизм хранения GitHub-токенов, лучше использовать его и не создавать дублирующее хранилище.

5. Проверка Git Pull и Git Push

После обновления токена проверим получение изменений:

git fetch origin main

Если ошибок нет, доступ на чтение работает.

Для проверки возможности отправки изменений:

git push --dry-run origin main

Команда проверяет отправку без фактического обновления удалённой ветки, хотя не гарантирует успешное прохождение всех серверных проверок при последующем реальном Push.

Если имеются готовые локальные коммиты, их можно отправить:

git push origin main

6. Распространённые ошибки GitHub Token

Ошибка 403: Write access to repository not granted

remote: Write access to repository not granted.
fatal: unable to access ... error: 403

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

Решение:

Откройте настройки токена GitHub.
Проверьте выбранный репозиторий.
Установите Contents: Read and write.
Сохраните разрешения.
Повторите Push.

Ошибка при изменении GitHub Actions workflow

refusing to allow a Personal Access Token
to create or update workflow
without workflow scope

Ошибка возникает, если коммит добавляет или изменяет файлы:

.github/workflows/*.yml

Для Fine-grained Token необходимо разрешение Workflows: Read and write, а для Classic Token — scope workflow вместе с необходимыми правами к репозиторию.

После изменения разрешений повторите отправку.

Ошибка could not read Username

fatal: could not read Username for 'https://github.com'

Git не может получить учётные данные.

Проверьте настройки Credential Helper, метод авторизации в CMS и правильность адреса репозитория.

После неудачного Push изменённых файлов больше нет

Это распространённая ситуация.

Например, система выполнила:

git commit -m "Update website"

Но последующий git push завершился ошибкой.

В этом случае изменения уже сохранены в локальном коммите, поэтому git status может не показывать изменённых файлов.

Проверьте:

git status -sb

Если отображается:

## main...origin/main [ahead 1]

это означает, что один локальный коммит ещё не отправлен на GitHub.

После исправления авторизации достаточно выполнить:

git push origin main

Повторно создавать коммит не требуется.

Ошибка non-fast-forward

Если удалённый репозиторий содержит новые коммиты, которых нет локально, Git может отклонить отправку.

Не следует сразу использовать git push --force.

Сначала проверьте состояние веток и сохраните несохранённые изменения. Затем синхронизируйте историю подходящим способом.

7. Как понять, что репозиторий синхронизирован

Выполните:

git status -sb

Пример полностью синхронизированного репозитория:

## main...origin/main

Если указано [ahead 2], локальная ветка содержит два неотправленных коммита.

Если указано [behind 3], удалённая ветка содержит три коммита, которые ещё не получены локально.

Для детальной проверки:

git rev-list --left-right --count HEAD...origin/main

Результат 0 0 означает, что локальная и удалённая ветки находятся на одном коммите.

8. Рекомендации по безопасности

Не публикуйте токены в исходном коде, репозитории GitHub, скриншотах и логах.

Для каждого сервера или проекта желательно создавать отдельный токен с минимальными необходимыми правами.

При подозрении на утечку токен следует немедленно отозвать и выпустить новый.

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

Заключение

Fine-grained Personal Access Token — удобный способ организовать доступ к GitHub для сайтов, серверов и внешних приложений.

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

Главное — ограничивать права доступа, учитывать необходимость отдельных разрешений для GitHub Actions и помнить, что Git Commit и Git Push являются разными операциями.

Официальная документация GitHub: