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

Коммиты удалить нельзя, но можно переключить указатель ветки на один шаг назад
git reset --hard HEAD~1
Тогда последующий коммит «исчезнет» из истории.
Но на скрине вы вообще не находитесь ни в какой ветке. Не забудьте создать ветку в этом месте, чтобы не потерять работу.

В интерфейсе GitHub есть специальная кнопка для этого.

Git это модульная система. Некоторые компоненты нужно устанавливать дополнительно, в том числе Git LFS for GitHub

Но зачем ты пихаешь в репозиторий архивы с резервными копиями?

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

git log --name-status --diff-filter=D # посмотри какие коммиты удалили файлы
git revert 0c76ed82d8a98bb9cae19a74fe4733c4f0c650d5 # отмени операцию удаления

Проект скачивается командой
git clone адрес_проекта
При этом связь с гибхабом настраивается автоматически

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

могут выкладывать в проект свои версии

Не могут. Гит это не какой-то FTP-сервер, куда можно выкладывать файлы. Ты можешь только синхронизировать свою локальную ветку и внешнюю на сервере.

в команде непонятно как сохранятся и объединятся правки

Почитай инструкцию к гиту и всё станет понятно. Если вышестоящая ветка (сервер) содержит коммиты, которых ты ещё не видел, то ты просто не сможешь отправить (push). Тебе придётся сначала скачать серверную версию ветки (fetch) и потом объединить на своём компьютере две версии кода (merge).
Если вы работали над разными фрагментами файла, то слияние произойдёт автоматически и ничего не затрётся.
Получится новый файл, который содержит общую работу. Потом ты сможешь отправить уже свою работу во внешний репозиторий (сервер).

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

Не совсем понимаю, как настроить синхронизацию папок именно с сайтом через гитхаб

Это называется CI/CD. Доставка файлов на собственно на сайт настраивается отдельно. Не надо ставить гит на сервер.

Нормально ли в гитхаб завести репозиторий типа песочницы, и хранить там разные куски кода

Репозиторий заводить для этого не очень удобно. Лучше храни куски кода на https://gist.github.com.

Удалить Pull Request невозможно, разве только закрыть его, да и не нужно ничего удалять для доработки задачи! Просто вернитесь в свою тематическую ветку. Добавьте новые коммиты с исправлениями и отправьте их на гитхаб. Pull Request обновится автоматически.

Даже если вы закрыли пиар, но продолжили работать в той же ветке, то последующий пуш просто заново откроет этот же пиар.

Аналогично если на Code Review будут замечания, то вы их просто исправляете локально в той же тематической ветке и пушите. Доработки сразу попадут в Pull Request.

Вас унесло совсем не в ту степь. Изначальная проблема думаю в том, что у вас нет прав на запись в свой репозиторий — Remote rejected. При первом пуше обычно просит авторизоваться. Это было сделано?

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

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

Причина озвучена в сообщении. Вы пытаетесь «смёржить» ветки, которые не имеют общей истории. Зачем?
Решений могу предложить несколько.
1. Вместо merge используйте команду rebase. Это пересоберёт вливаемую ветку поверх базовой.
2. У команды merge есть опция для игнорирования этой ошибки: --allow-unrelated-histories
Последний вариант используют когда объединяются истории двух проектов, которые начали свою жизнь независимо друг от друга.

Очень просто. Вот один из способов.

git reset --soft HEAD~2 # отменить два последних коммита
# с опцией --soft состояние проекта в рабочем каталоге не изменится и ничего не потеряешь
# и все локальные изменения после первого коммита автоматически поместятся в индекс
git commit # создать коммит заново.

В следующий раз вместо того, чтобы создавать дополнительный исправляющий коммит, просто пересоздавай предыдущий «плохой» коммит с помощью команды git commit --amend

Ох уж эти трудности перевода)) 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

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

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

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

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

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

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

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, то вылезет окошко выбора способа авторизации.

Pull Request делают только тогда, когда нет прав напрямую коммитить в ветку. В твоей же ситуации это сейчас бесполезная операция. Определись, как будет называться твоя главная ветка. Похоже на гитхабе у тебя основная ветка называется main, а локально ты создал master. Двух мастеров, как ты написал, быть не может. В одном репозитории невозможно создать две ветки с одним именем.

Твоя команда
git push -u origin master
отправляет твою текущую локальную ветку master в такую же ветку master на гитхабе и настраивает связь между ними (ключ -u).
Если ты хочешь отправлять из локальной master в вышестоящий main, то пиши иначе
git push -u origin master:main
После того как связь создана, то дальше можно отправлять короткой командой
git push

Лучше переименовать локальный master чтобы не путаться
git branch -M main

Так нужно было не только файлы с кодом на флешку скопировать, но и сам локальный репозиторий, который в папке .git. И ты бы продолжил на другом компьютере коммитить в репозиторий. Git хранит свой репозиторий локально в папке проекта и интернет для работы с ним не нужен.

А правильней было копировать ТОЛЬКО сам репозиторий на флешку. И не в виде папки, а одним файлом, так надёжнее и быстрее. Для этого даже специально придумали команду git bundle. Затем на новом компьютере распаковываешь файл пакета и восстанавливаешь рабочий каталог.

Сам создал себе проблему на пустом месте, но она легко решаема:

Если ты вернулся на рабочий компьютер, то просто удали все файлы с кодом из рабочей папки и верни туда файлы с флешки. Git сам увидит какие файлы были удалены и какие изменены или добавлены. ВСЁ.
Останется закоммитить изменения и потом отправить их на гитхаб.

Либо если ты нашел другой компьютер с интернетом, то клонируй туда снова свой проект с гитхаба (надеюсь ты не забыл сделать push перед тем как копировать файлы на флешку?) и потом так же очисти рабочий каталог и запиши изменённый проект на это место.

Используй ссылку на raw

Раз первый коммит единственный и он тебе не нужен, то можно просто удалить репозиторий на GitHub и создать заново. Но можно и не пересоздавать:

# удалить все файлы в рабочей копии
git rm -r * 
# создать на месте первого коммита пустой коммит
git commit --allow-empty --amend --message "Initial commit" 
# отправить текущую ветку на GitHub 
git push --force

Получишь чистый репозиторий с начальным пустым коммитом.
Сам пустой коммит можно использовать как основу для построения своего дерева коммитов.
Либо через ключ --amend замени его на что-то более осмысленное.

А ещё лучше не заниматься ерундой, исправить код и исправить коммит ключиком --amend