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

Ошибка возникает из-за проблем с биллингом: неоплаченные счета, активные подписки или некорректные данные оплаты. Проверьте раздел Settings → Billing & plans, обновите данные и отключите подписки. Если проблема не решается, обратитесь в GitHub Support.

Тут возможна путаница в терминологии.

Гитигнор не удаляет файлы из отслеживания, а скорее наоборот — игнор убирает файлы из списка неотслеживаемых (Untracked). Чтобы случайно не начать их отслеживать (случайно не добавить файлы в репозиторий).

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

Ну и ваше правило избыточно. Достаточно просто
__pycache__/

Вас пометили как спамера. Пишите в Support, чтобы разблокировали.

у меня не связывается папка B2 c репозиторием с гитхаба

Папка B2 автоматически связывается с гитхабом уже в момент клонирования туда репозитория.

Но вы это не видите, так как инициализировали в папке packages пустой репозиторий и именно для него VSCode и показывает кнопку Publish Branch.

.
└───yyy.loc
    ├───.git 
    └───packages
        ├───.git # пустой репо созданный git init
        └───B2
            └───.git

А чтобы VSCode увидел вложенный репо, лежащий в папке packages/B2 вам надо в папке packages тоже создать .gitignore и прописать в нем /B2/

Вы же сами увидели в vscode — что произошло. Вы забыли обновить ветку и начали строить вторую цепочку коммитов. Ваша ветка раздвоилась (diverged).

Гит вам тоже всё подробно пояснил, что нельзя пушить в другую ветку и предлагает вам сначала объединить разные ветки в одну используя pull.

Но тут вылезла другая проблема, что у вас немного недонастроен гит. В новых версиях он просит вас уточнить, каким методом вы хотите объединять ветки? Можно путем создания коммита слияния, а можно путем пересаживания вашей текущей ветки main на вершину вышестоящей ветки origin/main, чтобы история осталась простой и линейной, без этих разветвлений и слияний.

Первая стратегия задается командой
git config pull.rebase false # merge
И это поведение по-умолчанию которое было раньше. Рекоменду вам его и выбрать. Эта команда выполняется один раз и больше вам не потребуется.

А затем просто повторите git pull и всё сработает. Разве что могут возникнуть конфликт, но это уже другая тема.

Если хотите сохранить линейную историю то можно принудительно вызвать вторую стратегию только для одного раза
git pull --rebase

Гуглить фразу failed to push (не удалось отправить) бесполезно. Это слишком абстрактное описание проблемы. Причины могут быть самые разные.

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

На данном этапе вам проще удалить репозиторий
rm -rf ".git"
И начать заново. Но не пихать в коммит что попало, git add . а индексировать только нужные файлы.

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

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

Git теперь поддерживает так называемое выборочное скачивание содержимого через механизм sparse-checkout. Это позволяет вам работать только с нужными файлами или каталогами, исключая остальные, такие как node_modules.

# Клонировать репозиторий с фильтром, чтобы не загружать все файлы сразу
git clone --filter=blob:none --sparse https://example.com/repo.git
cd repo
# Инициализировать выборочную загрузку
git sparse-checkout init --no-cone

Нужно отредактировать файл .git/info/sparse-checkout:

# включить все файлы
/*
# кроме одной папки
!/node_modules/

Применить настройки

# Докачать всё, кроме папки node_modules
git sparse-checkout reapply

После выполнения этих команд Git скачает весь репозиторий, исключая указанный каталог node_modules. Вы сможете работать с репозиторием, не загружая лишние данные. Если потребуется вернуть node_modules, достаточно удалить соответствующее правило из файла sparse-checkout и снова выполнить git sparse-checkout reapply

по мнению status никаких неотслеживаемых файлов нет, а по мнению pull есть неотслеживаемые файлы которые будут перезаписаны. Как так?

Легко! В вышестояшем репозитории эта папка закоммичена. При pull возникает конфликт.

А вот кстати и коммит который пытаюсь спулить:
[htdocs]$ git status

Коммит то где? Статус рабочего каталога это не коммит.

Что может быть не так?

Забудьте про команды типа

git add --all .
git commit -am "..."

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

И покажите свой .gitignore

Если вы хотите аутентификацию по ключу, то вам нужен remote с URL для SSH-протокола, а у вас тут HTTPS-протокол, на который ваши SSH-ключи никак не влияют — там аутентификация своя — по паролю, либо токену.

Скорее всего вам надо поменять ссылку на правильную.

git remote set-url origin git@gitlab.com:malashko/bla-bla-bla.git

Отменить все незакоммиченные изменения в рабочем каталоге поможет команда
git reset --hard

PS. Немного подумав мне теперь нравится такой универсальный и более корректный способ.

git restore --source=хеш_коммита --staged --worktree .

Затем не забудьте закоммитить новые изменения.

Указывая --source=хеш_коммита, вы говорите Git использовать содержимое файлов из этого коммита.

Флаг --staged значит, что изменения будут сразу проиндексированы, как если бы вы их добавили с помощью git add. Этот флаг особенно полезен, если вы хотите сбросить изменения, которые уже были добавлены в индекс, но ещё не закоммичены.

Флаг --worktree указывает Git восстановить файлы в рабочем каталоге до состояния указанного коммита. Это означает, что любые незакоммиченные изменения в рабочих файлах будут сброшены, и файлы будут восстановлены до состояния, соответствующего указанному коммиту.

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

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

Чем вам вообще не устроил официальный GitHub CLI?
gh repo create Sushilka
Одна строка вместо вашей портянки и никакие токены не нужны.

Чтобы прекратить отслеживание версий в случайно созданном репозитории в каталоге C:\Users\<МойПользователь>, можно воспользоваться командой в Git Bash:

rm -r "~/.git"

Команда удалит каталог .git и все его содержимое (рекурсивно) из указанного пути. В данном случае, путь указывает на домашний каталог пользователя (обозначенный как ~)
.git — это скрытый каталог, используемый Git для хранения всех данных о репозитории (коммиты, история, конфигурация и т. д.). Удаление этого каталога приведет к удалению всей информации о репозитории, фактически «разгитив» проект.

Это может быть связано с тем, что ваш аккаунт подвергся ограничению за нарушение правил сервиса — своего рода «теневой бан». Рекомендую проверить свою почту на наличие писем от GitHub с темой Your account has been flagged. Если такое письмо есть, вам нужно будет следовать инструкциям в нем, чтобы разблокировать свой аккаунт.

Не надо ничего добавлять. В интерфейсе Visual Studio уже всё есть.
Кликаете на коммит, на который хотите сбросить историю и выбираете Reset — Keep Changes (--mixed)
В русском интерфейсе это наверное будет Сброс — Оставить изменения. Аналог смешанного сброса в TortoiseGit

Смешанный режим это --mixed — откатывает коммиты и индекс: оставляет изменения в рабочем каталоге, но очищает индекс. Это режим по умолчанию команды reset без опций.
Мягкий режим это --soft, когда делается всё то же, что и выше, но индекс не трогается.
То что вы отметили стрелкой на скрине в комментариях это вообще revertи он не годится для причесывания истории.

Чтобы игнорировать содержимое вложенного репозитория, ничего делать не нужно — Git уже всё за вас придумал. Он автоматически игнорирует рабочий каталог, в котором находится .git. Игнорирует все файлы, даже закоммиченные.

Merge Request — это запрос на слияние веток. Нет такого понятия, как «слияние коммитов». Сливаться будет вся цепочка коммитов, которая ответвилась от базовой ветки, а не только тот коммит, который существовал в ветке на момент создания запроса на слияние.

Чтобы создать три запроса, вам нужно раскидать эти коммиты по трем разным веткам.

Для каждого запроса на слияние создается отдельная ветка, потому что нельзя одну и ту же ветку слить дважды разными запросами. Хотите новый запрос — создавайте новую ветку. Ветка создается не откуда попало, а от главной ветки, в которую вы хотите вливаться.

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

@echo off
chcp 1251 >nul
echo %date% %time% >spisok.txt

setlocal enabledelayedexpansion
set "separator=, "  REM выведем названия через запятую

set "line="
for %%f in (*) do (
    if defined line (
        set "line=!line!%separator%%%f"
    ) else (
        set "line=%%f"
    )
)

echo !line! >> spisok.txt
endlocal

Использвую GitHub Desktop

Зачем вы его используете? Чего именно вам не хватает в Git-клиенте встроенном в Visual Studio?

Как удалить файл из репозитория, но оставить в рабочем каталоге? Это просто сделать в терминале.

git rm --cached "путь/к/файлу"
git commit

Но это сохранит файл только на одном компьютере. Если вы работаете с проектом не один, то файл удалится у коллег, когда они обновятся. Затем им придется руками восстановить файл из репозитория примерно так.
git checkout HEAD~1 -- "путь/к/файлу"

Комментариии в файле .gitignore начинаются с символа решетки # в начале строки.
Тут нам помогает подсветка синтаксиса и правильные комментарии выглядят затемненными.
Вы же испортили правило дописав посторонние символы в конец и поэтому оно у вас не работает.