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

Всё очень просто. На портах 80/443 вешаете не сайт, а обратный прокси.
Для Proxmox уже есть готовый контейнер Nginx Proxy Manager LXC
В нем разруливаете сколько угодно сайтов на вашем белом IP, там управление мышкой в веб-интерфейсе.
И сертификаты для https там создаются легко.

Если нужно вытащить отдельные файлы из другой ветки, используйте checkout
git checkout ветка -- путь/к/файлу
Это извлечет файл в рабочий каталог. Останется только его закоммитить в текущей ветке.

remote amvera already exists

Вы пытаетесь добавить remote с именем amvera,

git remote add amvera https://git.amvera.ru/<имя-пользователя>/<транслитерированное-имя-проекта>

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

Подскажите, что с этим можно сделать?

Если вы хотите заменить ранее добавленный адрес, то либо предварительно удалите предыдущий remote
git remote remove amvera
либо используйте команду замены
git remote set-url amvera ...

Почитайте, что делает опция --hard команды reset.

Историю изменения коммита посмотреть невозможно, так как это неизменяемая сущность по определению. Через amend вы лишь создаёте новый коммит и перемещаете указатель текущего состояния на него. Эти перемещения вы видите в локальном журнале reflog. Вы не можете видеть reflog внешних репозиториев. В лучшем случае, вы увидите историю «изменений» в Pull Request на GitHub.

Я имею ввиду предыдущую версию коммита до amend. Локально же можно переключиться на него через checkout.

Эти осиротевшие коммиты не удаляются сразу, поэтому вы некоторое время ещё можете их извлечь из репозитория через checkout или reset. Но они не принадлежат никакой ветке, поэтому никуда не отправляются при push и не получаются при fetch или clone, поэтому вы не сможете на них переключиться, так как их нет локально. Они остались в «мусоре» внешнего репозитория, который не скачивается при clone.

Нет, рекурсия работать не будет. Гит увидит, что внутри каталога лежит вложенный репозиторий и проигнорирует его. А в своей базе пометит этот подкаталог как поддерево (subtree), чтобы не сломать.

Вы пытаетесь соорудить какой-то жуткий костыль только лишь потому, что поленились изучить инструмент, в котором работаете. Поэтому для вас Git сейчас представляется как некая шайтан-машина, которой вы скармливаете команды, которые не понимаете, и в результате получаете ещё более непонятные «неожиданные результаты». Просто потратьте несколько дней, чтобы изучить азы. Не зубрите непонятные команды, а постарайтесь понять логику гита. А она — эта логика предельно проста и гениальна.

не является сложной задачей что-либо сломать в своем проекте

Сломать что-то в гите довольно сложно. Вам может только показаться что всё сломалось, но это лишь потому, что вы не понимаете, что делаете.

каким-то образом снес половину коммитов

Коммиты в гите — это неизменяемые сущности. Можно лишь создать новые «на замену», но старые не исчезают. Коммиты невозможно удалить без специальных команд очистки мусора.
Вам показалось что коммиты исчезли, но на самом деле они все остались в репозитории, вы просто их не видите в текущей ветке. Но всё легко откатывается назад, используя журнал Reflog.

Поэтому было бы неплохо как-либо сохранять прошлые версии Git репозитория

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

Мой вам совет: Пройдите 16 коротких бесплатных уроков и полу́чите просветление.

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

Например вы можете удалить папку в рабочем каталоге и затем не забыть закоммитить это изменение.

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

git rm —cached ".idea"
git commit -m "Delete .idea"

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

Запомните! Простое редактирование файла .gitignore не удаляет никакие файлы из репозитория. Вам надо удалить файлы самостоятельно, создав коммит удаления.

Гит — это распределенная система. Мы можем иметь много равноправных репозиториев и обмениваться информацией между ними. Тот репозиторий, в который мы сейчас коммитим, будет локальным. А другие репозитории, в которые отправляем (push) или из которых получаем (fetch), они внешние (вышестоящие, upstream, remotely)
Часто говорят удаленные, но это не очень уместный перевод слова remote в данном контексте. Потому что появляются странные формулировки типа «удалить удаленный»

Именем upstream ещё принято обозначать исходный репозиторий, от которого мы сделали форк на GitHub, так как имя origin уже занято и указывает на форк. Поэтому адрес исходного репозитория, при необходимости, сохраняем в переменной upstream. В данном контексте это просто традиция, и назвать ссылки на внешние репозитории мы вольны как угодно. Команда git remote лишь создаёт переменные, в которых мы храним URL внешних репозиториев, чтобы затем использовать имя переменной в командах, вместо того, чтобы писать длинный URL.

Попробовал отправить для теста — вылезло привычное окно Credential Manager с выбором способа авторизации. Выбрал через браузер и всё ушло как по маслу в пару кликов. И никакой возни с SSH-ключами.


Какая у вас версия Git? Какая операционка?
Нормально установленный Git использует Credential Manager для авторизации на серверах.

у всех работает сразу пуш и не требует аутентификации

Это конечно же не так. В первый раз всегда требуется авторизация.

Не знаю, что делать, и даже гайда нет по этому поводу нормально в интернете

Опять говорите неправду. В справке самого Bitbucket сказано, что нужно создать пароль приложения.
Из соображений безопасности, обычные пароли запрещены. Как я написал выше, мне лень и предпочитаю просто кликнуть мышкой и разрешить доступ.

Вы не дочитали до конца сообщение об ошибке

Hint: You have divergent branches and need to specify how to reconcile them.
Hint: You can do so by running one of the following commands sometime before
Hint: your next pull:
Hint: 
Hint:   git config pull.rebase false  # merge
Hint:   git config pull.rebase true   # rebase
Hint:   git config pull.ff only       # fast-forward only
Hint: 
Hint: You can replace "git config" with "git config --global" to set a default
Hint: preference for all repositories. You can also pass --rebase, --no-rebase,
Hint: or --ff-only on the command line to override the configured default per
Hint: invocation.

Гит вам говорит, что история веток разошлась и нужно явно указать, каким методом сливать разные ветки при pull.
Обычно принято использовать метод merge, поэтому мы либо каждый раз это уточняем:
git pull --no-rebase
Либо сохраняем глобальный параметр для всех ваших репозиториев:
git config --global pull.rebase false

Пробовали делать Rescan? Чтобы сервер узнал, что агент обновился.

Вы не можете войти в каталог, потому что это не каталог вовсе, а ссылка. Стрелочка как бы намекает.
Это может быть символическая ссылка (symlink), либо подмодуль (submodule), либо вложенный репозиторий (subtree). Скорее всего последнее и вы ранее инициализировали дополнительный репозиторий внутри той папки. Гит это распознаёт и не будет добавлять содержимое каталога в вышестоящий репозиторий. Поэтому гитахабу нечего вам показать внутри того каталога, так как там пусто. Содержимое папки осталось только в рабочем каталоге и не попало в репозиторий.

Если это так, то вот тут пример как лечить.

• Удалить папку .git из подкаталога Originalite
  
• Удалить эту ссылку из репо git rm --cached Originalite
  
• Затем таки добавить папку в репо git add Originalite
  
• Закоммитить и отправить на гитхаб.
  

В команде нет ошибок

Создайте файл 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?

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

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