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

Вы же сами увидели в 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 восстановить файлы в рабочем каталоге до состояния указанного коммита. Это означает, что любые незакоммиченные изменения в рабочих файлах будут сброшены, и файлы будут восстановлены до состояния, соответствующего указанному коммиту.

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

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

rm -r "~/.git"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

он просит ввести описание

Всё верно. Запускается текстовый редактор с заготовкой сообщения коммита. Вам нужно ввести свой текст тут. А всё что закомментировано — будет отброшено.

ввожу несколько символов

По скрину не заметно, что вы что-то написали.

и так зависает

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

Если переоткрыть командную строку и запустить опять он говорит что есть swap файл

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

говорит удалить его

Если вам трудно работать в vim, то просто переустановите гит, и на шаге, где предлагается выбрать редактор — укажите из списка ваш любимый редактор. Если тот редактор ещё не установлен, то там есть ссылка на сайт, откуда можно его установить. Затем в мастере делаем шаг назад и снова вперед. Тогда редактор становится доступным.

Поиск по аналогичным вопросам говорит, что состояние каталога (modified content, untracked content) возникает при наличии вложенного репозитория внутри него. Такой каталог будет полностью игнорироваться вышестоящим репозиторием, так как нельзя закоммитить один репозиторий внутрь другого.

Если вас напрягает это сообщение в статусе, то нужно удалить вложенный репо

# удалите папку .git, которая внутри каталога bitrix 
rm -rf "bitrix/.git"
# скажите гиту, чтобы он забыл, что перед этим видел там вложенный репозиторий 
git rm --cached "bitrix/"

Чтобы git pull без указания репозитория и ветки сам понял откуда брать обновления, вы должны эту информацию ранее сообщить гиту. Потому что внешний репозиторий не обязан называться origin, а название внешней ветки не всегда совпадает с локальной. Вы читали подсказку которую вам гит дал при неудачной git pull? Там он вам сообщил, что текущая локальная ветка не связана ни с какой веткой внешнего репозитория и подсказал какой командой эту связь создать. Но обычно мы эту связь создаем автоматически при первой отправке новой ветки, добавив ключик -u в команду push. Полное название ключа --set-upstream. Когда вы пушите через графический интерфейс, то там тоже должна быть галка для этого.

Git удалил коммит

Коммиты удалить довольно сложно. И случайно это сделать вы уж точно не сможете.

Как нормально переключаться, чтобы гит не удалял ничего?

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

вообще 1 лог остался изначальный

Эта фраза вообще не понятна.

если созданы новые файлы или переименованы, и ты возвращаешься, то он их не удаляет

Это гит так заботится о вас. Он сам постарается не уничтожать вашу несохраненную работу, которая лежит незакоммиченная в рабочем каталоге. Это не баг, а фича. С какого перепугу он должен уничтожать что-то?

git checkout master
git pull origin
git checkout branch-b
git merge master

Это всё можно заменить одной командой
git pull origin master

В этот момент процесс останавливается на моменте создания коммита слияния и вам нужно используя свой текстовый редактор разрешить все конфликты. Но гораздо эффективнее использовать инструменты разрешения конфликтов встроенные в графические Git-клиенты (рекомендую SmartGit либо IDE от JetBrains)

Далее завершаем слияние

git add .
git push origin

Тут вы забыли про git commit и указывать origin это лишнее, так как у вас ветка уже связана с вышестоящей. Но на самом деле достаточно всего одной команды для завершения

git merge --continue
git push # ну и отправить результат

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

git checkout --orphan second
git pull second second # во второй репе ветка называется second
git switch master
git merge second --allow-unrelated-histories
# решаю конфликты

Эти манипуляции можно заменить одной командой
git pull second second --allow-unrelated-histories
Результат будет идентичный.

хочу указать у коммита 0f6a3f0 родительским коммитом d5c58d8

Коммиты в гите неизменяемы. Если изначально родителя не было, то вы не прицепите его постфактум. Но вы можете пересадить ветку second на вершину master, пересобрав коммиты заново.

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

git fetch second # скачать все коммиты из второго репо
git switch second # перейти в ветку second
git rebase master # пересобрать ветку second с вершины ветки master
  dropping 0f6a3f0 third, "two" -- patch contents already upstream
  Successfully rebased and updated refs/heads/second.
git switch master # вернуться в master
git merge second --no-ff # влить second в master

Получим:

git log --oneline --graph
*   13dddb5 (HEAD -> master) Merge branch 'second'
|\
| * 515f80e (second) fourth, "three"
|/
* d5c58d8 second, "two"
* fcc376b first, "one"

Коммит third, "two" исчез из истории (дропнут) во время rebase, так как он полностью повторяет состояние second, "two"

Но если вам надо действительно последовательную историю, то не надо создавать коммит слияния. Не используйте ключ --no-ff в последней команде. Это просто установит указатель master на вершину.
И получится линейная история

git log --oneline --graph
* 515f80e (HEAD -> master, second) fourth, "three"
* d5c58d8 second, "two"
* fcc376b first, "one"

Вы перепутали команду. Слияние делается не через Checkout, а через Merge. И предварительно, через filter-repo, нужно подчистить и реорганизовать тот репозиторий, откуда хотите сливать недостающее, чтобы оставить только нужное и в правильном каталоге.