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

Делай осмысленные сообщения коммитов. Эти шифровки с датами тебя только запутают.

Сам факт, что при push ты видишь много коммитов, не является ошибкой. Не надо пытаться это исправить.
Это лишь признак того, что твоя ветка не основана на актуальном мастере изначально и в процессе работы подгружались обновления, либо ты баловался c push --force что равносильно пересборке ветки заново через rebase.
После такого принудительного push, на других компах уже недостаточно обычного pull. Придётся сделать pull в режиме --rebase, иначе получится каша из коммитов.

Советую для работы с самим репозиторием параллельно использовать нормальный Git-клиент, который наглядно показывает дерево коммитов. SmartGit идеален для этого. Так будет намного понятнее что происходит.

Поправь ошибку в URL

git remote set-url origin git@bitbucket.org:myacc/myproj.git

Сообщение Permission denied сбивает с толку. Git при любой проблеме с передачей данных пишет Permission denied, хотя ошибка не в правах доступа, а в том, что Git просто не нашел репозиторий по указанному адресу. ...does not appear to be a git repository

Коммитить можно только в локальный репозиторий, а во внешний репозиторий мы пушим.
Ссылки на внешние репозитории показываются командой git remote -v
Если в VSCode, то открой панель Source Control и выбери раздел Remotes. Там всё увидишь.

А чтобы связать ветки используется такая команда

git branch --set-upstream-to=<внешний-репозиторий>/<внешняя-ветка> <локальная-ветка>

---------
Но ты всё усложняешь. Если зачем-то вручную создал ветку, то и связь настроить придётся руками. Из вопроса не до конца понятно, что конкретно ты сделал. Предположу что ты клонировал на сервер свой репозиторий.
git clone <URL>
Такая команда автоматически создаст remote с именем origin в которой будет храниться URL вышестоящего репозитория, распакует главную ветку origin/main в локальную ветку main и сразу создаст связь между ними.

Ты хочешь распаковать какую-то другую ветку и делаешь это сложным путем?

git branch feature # создать пустую ветку с именем feature
git switch feature # переключиться в эту новую ветку
# но свежесозданная ветка не связана ни с какой внешней, поэтому следующей командой
# придётся указать откуда и что скачивать
git pull origin feature # влить внешнюю ветку origin/feature в текущую локальную ветку
# но проще ветки сначала связать
git  branch --set-upstream-to=origin/feature feature
# и тогда заработает простой pull
git pull

Но тебе всё это не нужно на самом деле!
Достаточно после клонирования просто написать
git switch origin/feature

Одна строчка сделает всё вышеперечисленное. Создаст локально ветку с таким же именем, распакует в неё содержимое внешней ветки и создаст связь между локальной и внешней веткой.
Если потом, находясь в этой ветке, выполнишь короткую команду git pull, то увидишь что всё связано и скачивается откуда надо.

И даже можно сделать ещё проще. Уже во время клонирования сразу распаковать нужную ветку.
git clone --branch feature <URL>

% git pull                                      
У текущей ветки нет информации об отслеживании.
Пожалуйста, укажите с какой веткой вы хотите слить изменения.
Для дополнительной информации, смотрите git-pull(1).

    git pull <внешний-репозиторий> <внешняя-ветка>

Если вы хотите указать информацию о отслеживаемой ветке, выполните:

    git branch --set-upstream-to=<внешний-репозиторий>/<внешняя-ветка> <локальная-ветка>

Похоже ты добавил remote с именем MyBot, но забыл связать текущую ветку master с какой-либо вышестоящей.
Поэтому Git не знает откуда скачивать и просит тебя указать откуда конкретно ты хочешь загрузить коммиты.

Например так:

# скачать ветку master из внешнего репозитория MyBot и слить с текущей локальной веткой
git pull MyBot master

Либо привязать к текущей ветке вышестоящую чтобы заработал pull без параметров:

# связать локальную ветку master c внешней веткой master
git branch --set-upstream-to=MyBot/master master

Ты первым делом должен был добавить строку /database/ в файл .gitignore, который ты создашь в корне проекта, чтобы add . игнорировал эту папку.
Незачем загонять файлы базы под контроль версий.

Такое может произойти из-за неправильной настройки символа переноса строки.
Читай тут как исправить.

error: main.py: already exists in index
Это означает что патч пытается создать main.py, но он уже есть в твоём проекте.
Сначала удали лишний файл, потом продолжи применять патч: git am --continue

Ох уж эти трудности перевода)) remote обычно переводят на русский как удалённый. Но что если я захочу удалить remote? Удалить удалённый?
Поэтому лучше говорить «внешний», чтобы не путаться. Мы работаем с локальным репозиторием, а все остальные по отношению к нему будут внешними. В Git нет централизации, все репозитории равноправны и могут обмениваться информацией в произвольных направлениях.

Итак: у нас есть два внешних репозитория и хочется их синхронизировать? Без проблем.
Можно использовать локальный компьютер как вспомогательный.

Я сделал
git init
git remote add origin ....

Начало уже нелогичное. Ты же говоришь что уже выкачал репозиторий с сервера?
Т. е. выполнил git clone <server1>
Это уже создало копию репозитория и init не нужен. А ещё это автоматически создало ссылку origin тоже.

Дальше можно поменять адрес origin на второй сервер
git remote set-url origin <server2>

И сразу увидим в git status есть ли отличия.
Хотя нет, вру. Надо после смены адреса скачать к себе заново внешние ветки командой
git fetch
Только тогда будет что сравнивать.

Примерно так. Это первое что пришло в голову и пожалуй грубовато. Можно придумать более аккуратную схему.

Я бы лучше не удалял старый remote, а добавил новый. То что ты «скачал с сервера» пусть так и останется как origin. А «удалённый» репозиторий обозначим как upstream

git remote add upstream <server2>
git fetch upstream

Тогда мы сможем сравнивать любые ветки и синхронизировать.

Как форматировать .GITIGNORE для GITHUB?

Правильный ответ на поставленный вопрос — никак.
Файл .gitignore не используется в сервисе GitHub.

Но после публикации Release
Каждый раз в архиве пакета находятся все файлы из этого репозитория.

А ты ожидал чего-то другого? Что ты поместил в ветку, то и увидишь в релизе.
Добавление масок файлов в .gitignore не удаляет никакие файлы из проекта.
Хочешь удалить файл — удали его непосредственно из ветки репозитория.

Что означают строки с символами <<<<<<< и >>>>>>> в .gitignore?

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

<<<<<<< OURS 
=======
>>>>>>> THEIRS

файл XML должен загружаться по URL но не должен попадать в архив.

Используй для сайта и для архива с релизом разные ветки и будет тебе счастье. По умолчанию сайт GitHub Pages хранится в ветке gh-pages. Зачем ты свалил всё в кучу и используешь ветку master и для сайта и для самого проекта?

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

git log --name-status --graph --oneline --since=4.months -- ToModel*.php

Такие файлы добавляются в .gitignore так же, как и любой другой файл.
Но, подозреваю, что вопрос в другом. Хочется чтобы файлы исчезли из проекта?
Ты видишь, что файл никуда не исчез и сделал вывод, что файл не добавлен в игнор. Но это не так.
По сути .gitignore тебе совершенно не нужен, потому что добавление файла в игнор не удалит его автоматически из репозитория, если он ранее уже был добавлен в отслеживаемые. Этот файл нужен только чтобы случайно не добавить в репозиторий лишнее. Но даже он не помешает нам добавить любой файл в репо командой git add файл

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

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

Скорее всего pull предлагает сделать не после push, а после нажатия кнопки синхронизации в VSCode.
До того как собственно сделает сам push, спрашивает «а не хотите ли сначала обновиться?»
Более точный ответ мы увидим в консоли, смотри там что происходит.
Скачивать ветку заново сразу после отправки действительно нет никакого смысла.

Ветки создаются командой: git branch имя
Всё! Никаких коммитов дополнительно создавать не надо. Главное чтобы репозиторий уже содержал хотя-бы один коммит, чтобы веткам было куда указывать (ветка это лишь указатель на коммит).

Push отправляет конечно же не файлы а именно ветки. По умолчанию только одну ветку, которая текущая. Чтобы отправить сразу все, следует его об этом попросить: git push origin --all

Если капитан любит линейную историю то легко можно избавиться от коммита слияния:

git rebase origin/master databаse_branch

Эта команда пересадит ветку databаse_branch на вершину актуальной ветки database, которая судя по всему связана с веткой master в вышестоящем репозитории origin. Коммит слияния исчезнет.

Затем придётся принудительно обновить в вышестоящем репозитории эту ветку:

git push --force

И если кто-то её уже скачивал к себе, то попросить их обновиться через:

git pull databаse_branch --rebase

Как-то так. Я мог не угадать названия веток, так как по скрину не всё видно. Но принцип решения должен сработать.

Это называется перебазирование. Мы пересаживаем одну ветку на вершину другой ветки.
git rebase deps react-app
Но ветка react-app у тебя уже запушена, значит её придётся принудительно обновить во внешнем репозитории.
git push --force
И будь внимателен, если ветку react-app уже кто-то скачал себе, то ты их должен предупредить, чтобы они удалили её у себя и скачали заново. Либо обновили через git pull --rebase

Перед тем как применить новую аутентификацию, удали старую командой:

echo "url=https://github.com" | git credential reject

На твоём скрине я вижу обратное. Не появляются, а наоборот исчезают. И не табуляции, а пробелы.
По умолчанию в редакторах JetBrains удаляются лишние пробелы (trailing spaces) только в изменённых строках. Проверь это у себя в настройках редактора вот тут Editor / General / On Save


Но, по хорошему, надо эти косяки в коде везде поправить.

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

git reset $(git commit-tree HEAD^{tree} -m 'Новое начало истории')

Вторая команда очистит папку .git от мусора:
git gc --prune=now --aggressive

Ну и конечно отправить новое состояние ветки на гитхаб:
git push --force

Если у вас Windows, то работайте в git-bash, а не в стандартной командной строке.

Пароль не запрашивает почему? Потому что он уже сохранён в хранилище паролей.
Что нужно сделать чтобы пароль запросился снова? Нужно старый пароль удалить конечно же!
В разных операционных системах пароли хранятся по-разному и поэтому тебя первым делом попросили показать конфиг git config -l, чтобы уточнить способ очистки.

Но можно попробовать универсальный метод сброса авторизации:

echo "url=https://github.com" | git credential reject

Если теперь снова попробовать git push, то вылезет окошко выбора способа авторизации.