Сергей Кузнецов

Создайте файл script.cmd в папке main

@echo off
for %%l in (en kz au cz th) do (
    xcopy /E /I /Q /Y ru %%l
)

Затем перейдите в командной строке CMD в эту папку и запустите скрипт.

Вот то же самое, но через создание символических ссылок.

@echo off
for %%l in (en kz au cz th) do (
    mklink /D %%l ru
)

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

main
│   script.cmd
├───au
│   └───dir
│       │   index.html
│       ├───css
│       └───js
├───cz
│   └───dir
│       │   index.html
│       ├───css
│       └───js
├───en
│   └───dir
│       │   index.html
│       ├───css
│       └───js
├───kz
│   └───dir
│       │   index.html
│       ├───css
│       └───js
├───ru
│   └───dir
│       │   index.html
│       ├───css
│       └───js
└───th
    └───dir
        │   index.html
        ├───css
        └───js

В окне просмотра файлов есть кнопочка History — увидите все версии файла

пишет кто залил каждый коммит, на сайте гитхаба такой информации не нашел

Показывает не кто «залил», а кто создал коммит.
GitHub не хранит файлы, он хранит репозитории, а в репозиториях есть коммиты, которые подписаны их создателями. Сырую подпись можно увидеть по ссылке patch в окне просмотра коммита.

может быть из-за того, что файлы находятся в папке source

Вот сами и догадались. У вас в настройках стоит брать страницу из каталога docs, которого нет.
Вы все правильно поправили. Сейчас у вас создан Workflow, который запускает сборку проекта на серверах гитхаба, затем помещает файлы из папки build в корень ветки gh-pages и страница становится опубликованной.

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

Предполагаю, что коммиты вы хотите подписывать реальными именами авторов, поэтому храните настройки подписи не в глобальном конфиге, а в локальном конфиге конкретного локального репозитория. Надеюсь хоть репозитории то у вас разные?

git config --local user.name ...
git config --local user.email ...

Если хочется непременно разные аккаунты на гитхабе, то

Как разлогиниться в гитхабе?

Если отправляете по HTTPS, то придется каждый раз сбрасывать авторизацию после предыдущего пользователя

echo "url=https://github.com" | git credential reject

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

Для этого мы создаём в файле конфигурации ~/.ssh/config несколько виртуальных хостов

Host github-alice
        Hostname github.com
        IdentityFile=/home/user/.ssh/alice_key

Host github-bob
        Hostname github.com
        IdentityFile=/home/user/.ssh/bob_key

И поправьте ссылки на origin в своих репозиториях используя псевдоним виртуального хоста

git remote set-url origin git@github-alice:OWNER/alice-repo.git

Есть официальная инструкция

How do I use multiple accounts with the same hosting provider using SSH?

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

Принудительное удаление этих файлов решит проблему.

SSH не использую

Вы используете SSH, причем с ключами RSA.

В марте 2023 года закрытый SSH-ключ RSA GitHub.com был ненадолго предоставлен в общедоступном репозитории GitHub, поэтому его заменили. Если использовать ключи ECDSA или Ed25519, вы не заметите никаких изменений, и никаких действий не потребуется.

Если вы видите сообщение Host key verification failed, вам нужно удалить старый ключ, выполнив следующую команду:

ssh-keygen -R github.com

Воспользуйтесь инструкцией по установке с официального сайта Git LFS

GitHub это же сайт, его нельзя установить. Похоже вы пытаетесь установить программу GitHub Desktop, которая занимает примерно 200-300 МБ на диске после установки. Даже если вы сможете его переместить на другой диск, это вам мало поможет.

предлагает использовать либо одно, либо другое

Кто такое предлагает? Наоборот, в большинстве случаев хочется оставить и то и другое.

Как правильно решить этот конфликт?

Как обычно, у себя на компьютере подгружаете в свою ветку новые коммиты из целевой ветки common, которые там появились после того, как вы свою ветку feature создали. И в этот момент разрешаете конфликт локально, а вовсе не на гитлабе.

Верно. Если не делать коммит, то он и не получится.

Под памятью тут имеется в виду оперативная память. Видимо на хостинге она сильно ограничена.
Тут написано что клонирование прошло успешно и сбой прошел уже на этапе распаковки файлов в рабочий каталог.
Вы пробовали узнать что проиходит через git status?
Ну и сделать как советуют
git restore --source=HEAD :/

Permission to {repo} denied to {user}

Это говорит о том, что авторизация прошла успешно, но данному пользователю не предоставлено прав на запись в репозиторий. Ошиблись при создании токена.

Параметры user.name и user.email не имеют никакого отношения в вашим GitHub-аккаунтам.
Это лишь реквизиты, которыми будут подписаны новые коммиты на вашем компьютере и всё.
Вы же не думаете, что достаточно знать ваше полное имя и мыло, чтобы войти в аккаунт?

Если интересно, какой параметр в каком файле сохранён, воспользуйтесь командой.
git config --list --show-origin
system лежат в каталоге самого гита и действуют глобально на репозитории всего компьютера.
global хранятся в каталоге пользователя и влияют на все репозитории текущего пользователя.
local сохраняются в каталоге репозитория и действуют только на этот репозиторий.
Одинаковые параметры могут дублироваться в разных конфигах и тогда используется самый локальный.

Но! Ваша ошибка при push связана лишь с неправильной авторизацией. Разбирайтесь с ней, а не с тем, как подписаны коммиты.

Авторство коммитов на авторизацию не влияет вообще, от слова совсем. Можете подписаться хоть как Билл Гейтс. После отправки коммитов на гитхаб они не изменятся. Коммиты вообще в принципе никогда не изменяются, по определению. Можно лишь их пересоздать заново с другим содержимым и описанием.

Команда git remote prune origin удалит ссылки на вышестоящие ветки, которых уже нет на сервере origin, но не тронет соответствующие локальные ветки, которые были с ними связаны.

Удалить локальные ветки, которые связаны с несуществующими внешними можно примерно таким скриптом:

#!/bin/bash

# Получить список веток, которых уже нет на внешнем сервере
missing_branches=$(git branch -vv | grep ': gone]' | awk '{print $1}')

# Удалить каждую локальную ветку, у которой удалена её вышестоящая ветка.
for branch in $missing_branches; do
    git branch -D $branch
done

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

GitHub Pages поддерживает только статические сайты, а EJS является шаблонизатором, работающим на стороне сервера. Вместо того, чтобы использовать EJS для рендеринга на клиентской стороне, вы можете предварительно сгенерировать HTML-файлы с помощью EJS на вашем локальном компьютере, а затем разместить их на GitHub Pages. Если ваш сайт зависит от серверных операций или динамического контента, вам нужно будет найти другой хостинг.

не позволяет использовать 1 ключ в нескольких репозиториях

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

Скорее всего нужно подсказать хосту, какой именно ключ использовать для каждого из подмодулей.
Для этого мы создаём в файле конфигурации ~/.ssh/config несколько виртуальных хостов

Host github.com-module-1
        Hostname github.com
        IdentityFile=/home/user/.ssh/module-1_deploy_key

Host github.com-module-2
        Hostname github.com
        IdentityFile=/home/user/.ssh/module-2_deploy_key

И поправьте ссылку на подмодуль в .gitmodules используя псевдоним виртуального хоста
git@github.com-module-1:OWNER/repo-submodule-1.git

Сам не проверял, пишу основываясь на официальную документацию GitHub:
Authentication / Connect with SSH / Managing deploy keys

У Git нет команды «подключиться к репозиторию». Да и как к нему подключаться, если репозиторий это просто каталог? Вы наверное пытаетесь утилитой ssh подключиться к какому-то серверу, на котором лежит репозиторий. А зачем? Git-хостинги не предоставляют доступа к командной оболочке своих серверов, это же не vps.

Восстановить очень легко, так как гит ничего не удаляет из репозитория, по крайней мере сразу.
Команда reset лишь переместила указатель ветки. Полностью удалить что-то крайне сложно.
Вы можете посмотреть через git reflog где был указатель до этого и вернуть его туда обратно.
git reset --hard HEAD@{1}
Данная команда вернёт ветку на состояние, помеченное на вашем скрине как HEAD@{1}
Либо можно скопировать непосредственно sha-хэш места, куда хотите вернуться.

Затем повторить отмену последнего коммита, но уже правильно:
git reset HEAD~1
Такая команда не будет изменять рабочий каталог, а значит ничего из него не удалит.

Другом ответе показали обходное решение с переходом на SSH-протокол.
Оно конечно сработает, но что, если нужно-таки работать через HTTPS?

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

Предварительно придется отменить старую неудачную авторизацию,
особенно если вы зачем-то ранее ввели пароль вместо токена.

echo "url=https://github.com" | git credential reject

На рабочем компе предпочитаю HTTPS, так как он удобнее и надежнее. Причем без токенов, достаточно OAuth-авторизации через браузер. После первого push вход происходит буквально в один клик.
Не надо никуда ходить, не надо создавать ключи или токены, всё работает автоматически.
Если у вас не предлагает такой авторизации, значит гит старый, либо неполный, установлен без credential manager.