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

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

Это не «вложенная» ветка, это у вас получится обычная ветка со слешем в названии.

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

Этот мануал в вашем случае не подходит. Там синхронизация односторонняя. Вы отправляете не на сайт, а в репозиторий на сервере. Затем хук извлекает содержимое ветки master в каталог с файлами сайта, затирая всё что там ранее мог изменить пользователь через админку.

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

если нажать pull или fetch all, то локальная версия изменений на сервере не видит.

А разве должен видеть? Fetch/Pull скачивает не файлы из рабочего каталога, а коммиты из репозитория. Это вообще разные сущности. Чтобы в репо попали изменения, их нужно коммитить, только так и не иначе.

Предлагаю не создавать bare-репозиторий без рабочего каталога, а инициализировать обычный репо прямо в каталоге сайта. Обновления не проталкивать через push, а забирать через pull, потому что гит не сможет отправить push в текущую ветку. Чтобы забрать изменения файлов с сервера, их нужно предварительно коммитить разумеется, так как pull скачивает не файлы, а коммиты. Pull лучше делать на чистом от изменений рабочем каталоге, поэтому можно запускать простой скрипт

git fetch # скачать обновления заранее, чтобы не ждать во время обновления файлов
git stash # временно спрятать локальные правки
git pull # применить обновления к сайту
git stash pop # вернуть локальные правки обратно

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

Я таким способом в своё время успешно синхронизировал правки между компьютером разработки и основным сервером, где работал продукт. Там тоже часть файлов изменялось сервером во время работы. Скрипт отрабатывает достаточно быстро, чтобы сервер не успел заметить откат файлов при stash.