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

Гит не просто «что-то говорит», а конкретно сообщает что вы находитесь в состоянии незаконченного перебазирования и сообщает «как убрать».
Вы должны либо продолжить и довести перебазирование до конца
git rebase --continue
Либо отменить процесс через
git rebase --abort

Я бы на вашем месте как раз отменил, так как вы делаете что-то странное. Сначала дропнули из истории один коммит, потом попытались применить его отмену и скорее всего получили сложный конфликт. Что вообще пытаетесь добиться?

Если вы, не осознав что rebase ещё не закончился, продолжили добавлять новые коммиты, то тогда завершите rebase. А потом смотрите что получилось.

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

Либо вы перепутали целевую ветку и отправляете изменения не туда.

PS. Так и есть. Вы перепутали ветки. Пытаетесь отправить изменения не в ту ветку, от которой создали свою тематическую. Вы забыли отправить на гитхаб ветку main, которую собственно и хотите менять. А ветка main что сейчас на гитхабе, это совершенно левая ветка.

Проще всего удалить локальный master, тогда и запрещать ничего не придётся.
Нет master — нет проблемы. А новые ветки создавайте от origin/master

В гите ничего нельзя удалить.
Чтобы отменить какое-то действие, можно создать новый коммит, который делает противоположное изменение.
Либо просто передвинуть указатель ветки назад, на состояние до слияния.
Всё это делается на локальной копии репозитория и затем отправляется на GitLab.

Cвоим amend вы фактически удалили тематическую ветку и создали новую версию.
После этого надо было отменить предыдущее слияние через reset.

Но текст ошибки говорит о том, что вы делаете новое слияние не завершив предыдущее.
Возможно слияние остановилось на конфликте, но вы проигнорировали это.
Определитесь что именно хотите сделать.
Либо разрешить конфликт и затем завершить слияние git merge --continue
Либо отказаться от слияния и всё отменить git merge --abort

Можно и не создавать, но будет неудобно. Особенно если вы привыкли коммитить всё без разбору, а не только нужные файлы. Файлы игноров уменьшают вероятность закоммитить мусор.

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

Можно это сделать как-то не на серверной винде, в идеале на домашке?

На домашке RDP официально отключен и включается только сторонними инструментами, что является нарушением лицензии.

Не создавайте пустой репозиторий, а клонируйте сразу с гитхаба.
И замените в вашем алгоритме https на ssh и всё заработает.
Только ссылка ssh выглядит чуть иначе и придется создать ключи.

Судя по документации, GitFlowPersistenceProvider не привязан к какому-то конкретному хостингу и позволяет отправлять реестр в любой внешний репозиторий.

Git заточен на отслеживание только текстовых файлов. Они будут храниться эффективно, без дублирования. Двоичные файлы будут сохраняться в репо каждый раз целиком, даже если изменили один байт.

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

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

Другое дело что у Bitbucket/GitHub/GitLab есть API, позволяющие вытаскивать информацию через него. И если эти API требуют авторизации, то вы наверное не сможете без авторизации обойтись. Это тоже к самому гиту не имеет отношения. Тут вы работаете лишь с API этих сайтов.

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

А чтобы объединить какие-то коммиты, вы должны поменять порядок коммитов в новой ветке, чтобы ваши коммиты оказались рядом. Только так. При этом как правило вылезут конфликты, из-за разного порядка коммитов. Вы точно хотите продолжать?

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

As soon as initial translation is completed, repos.git is ready to serve users. Pushes to repos.git will be translated to SVN and commits to SVN will be translated to Git.
Note, that repos.git is so called ‘bare’ Git repository, i.e. it does not contain working tree.

Никакой рабочий каталог он не синхронизирует.

Скрипт svn2git собирает Git-репозиторий локально, уже затем вы его отправляете в любой внешний репозиторий. Например, в GitLab.

Даже в инструкции просят устанавливать скрипт на ваш локальный компьютер, а не на сервер GitLab.

Install svn2git on a local workstation rather than the GitLab server

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

Pull Request в GitHub-репозитории можно только закрыть. Удалить созданный ранее PR невозможно.

Если нужен ответ на вопрос как расшифровать, то вот так:

import java.nio.ByteBuffer;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;

public class Main {

    public static void main(String[] args) {
        
        byte[] rawBytes = Charset.forName("Windows-1251")
                .encode("ГђВќГђВµ ГђВЅГђВ°").array();
        String asUTF8 = StandardCharsets.UTF_8
                .decode(ByteBuffer.wrap(rawBytes)).toString();
        byte[] bytes = StandardCharsets.ISO_8859_1
                .encode(asUTF8).array();
        String result = StandardCharsets.UTF_8
                .decode(ByteBuffer.wrap(bytes)).toString();

        System.out.println(result); // Не на ...йден...?
    }
}

Этот код не гарантирует полное восстановление конечно, но хотя бы текст станет читабельным.
Проблема в том что изначальный поток байтов utf-8 был интерпретирован как ISO-8859-1/Latin-1/ASCII, но сохранён снова как utf-8. Затем строка была выведена в консоль под видом строки Windows-1251.

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

Аккаунт, под которым вы делали push, никак не отразится на самих коммитах. Каким именем вы их подписали при создании, то имя и останется в них навсегда.

Клонирование с заменой файлов не делается никак. В гите нет такой команды.

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

Зачем вам Pull? Делайте Clone и всё автоматом свяжется.

exists and is not an empty directory

Клонировать мы должны либо в пустой каталог, либо в ещё не существующий.

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

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

git reset --hard

#### LibGit2Sharp
using (var repo = new Repository("path/to/your/repo"))
{
    Commit currentCommit = repo.Head.Tip;
    repo.Reset(ResetMode.Hard, currentCommit);
}