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

Там в меню вашей IDE есть ещё несколько методов откатить изменения.
Это же JetBrains? Все способы подробно описаны в справке, например вот как в IntelliJ IDEA

Reset удаляет все коммиты выше выбранного. Там предлагается четыре варианта этой команды. Отличия их в том, как поступить с изменениями в рабочем каталоге и в индексе.

Revert не удаляет коммит, а создаёт новый, который описывает действия необходимые для отмены выбранного коммита.

Undo позволяет отменить последний коммит. Но изменения коммита предлагает сохранить в новый changelist. Файлы в рабочем каталоге не изменятся и можно будет их подправить и заново закоммитить.

Drop — удобная команда для удаления произвольного коммита из середины истории. Под капотом там на самом деле выполняется интерактивный rebase, но в автоматическом режиме.

Revert Selected Changes напоминает Revert, но отменяет изменения отдельного файла, а не всего коммита. Эта команда доступна на Панели изменённых файлов.

Get позволяет вернуть любой файл к состоянию на определённый коммит в истории. Выберем файл любым удобным способом и контекстное меню Git | Show History покажет все коммиты, в которых изменялся данный файл. Кликнув на нужном коммите правой кнопкой увидим команду Get

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

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

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

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

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

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

В терминале пишем
git checkout хеш_коммита -- полное_имя_файла
и состояние файла вернётся к тому, что было после коммита с указанным хешем.

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

Форсированно похерить всю работу сделанную в мастере и заменить её веткой feature?
Удали мастер (это же всего лишь ссылка) и переименуй feature в master.

git checkout feature # удостовериться что мы в нужной ветке
git branch -d master # удалить ненужную ветку
git branch -M master # переименовать текущую ветку в master

ЗЫ
Но лучше делать через создание правильного нового коммита. Тогда не будет проблем в команде.
Переписал решение Станислав Бушуев в одну строку:

git checkout master # удостовериться что мы в нужной ветке
git merge --ff $(git commit-tree -p master -p feature -m "New feature" feature^{tree})

Наверное возможно даже так (если я правильно понял совет HuckF1nn):

git checkout master # удостовериться что мы в нужной ветке
git merge feature -X ort their # принудительно сливаем фичу в мастер

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

Можно ли это сделать у себя локально?
Конечно можно! После того, как переключитесь на новую ветку (я так понял, что имеется в виду локальный master), сделайте слияние с веткой feature командой:
git merge feature
Так можно проверить, как ваши правки будут работать, после того как их примут во внешнем репозиториии (наверное GitHub?). Главное не пытаться потом отправлять (git push) ветку master. Так как скорее всего рабочий процесс предполагает работу через запросы на слияние на сервере (Pull Request)

Такое ощущение, что у вас каша в голове и не понимаете что спрашиваете.

Добавление файла .gitignore не удаляет файл из репозитория. Оно лишь предотвращает автоматическое добавление файла в репозиторий при ближайшем индексировании (например через git add .), но даже игнор не запрещает нам начать отслеживать любой файл просто принудительно добавив его в индекс git add <file>

Однажды добавив файл в репозиторий, вы уже не сможете его оттуда удалить. Это если понимать под репозиторием всю его базу со всей историей.

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

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

1) По умолчанию, git push отправляет на сервер только одну ветку — текущую.
Чтобы отправить ветку developer, сначала переключитесь на неё.
git checkout developer
git push -u

Либо можно не переключаться, но явно указать, что и куда отправить
git push -u origin developer
Эта команда говорит: возьми ветку developer и отправь в репозиторий origin.
Флаг -u нужен чтобы сразу связать локальные ветки с создаваемыми удалёнными.

Хотя можно сказать гиту, чтобы он отправил сразу все локальные ветки

% git push -u --all 
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/.../repo.git
 * [new branch]      developer -> developer
Ветка «developer» отслеживает внешнюю ветку «developer» из «origin».
Ветка «feature/feature_some1» отслеживает внешнюю ветку «feature/feature_some1» из «origin».
Ветка «feature/feature_some2» отслеживает внешнюю ветку «feature/feature_some2» из «origin».
Ветка «master» отслеживает внешнюю ветку «master» из «origin».

Но если у вас есть локальная ветка, которую вы не хотите светить на сервере, то флаг -all не подойдет ))

2) Синтаксис названия feature/feature_some1 это не две ветки, feature и вложенная feature_some1
Это всё равно одна ветка. Но в графических клиентах такие ветки отображаются как вложенные, для удобства.
Создав вторую ветку с именем feature/feature_some2 получим такую картинку


Но никакой ветки feature не существует.

% git branch    
  developer
  feature/feature_some1
* feature/feature_some2
  master

3) Как сделать merge в ветку developer?
Перед слиянием убедиться, что рабочая копия не имеет незакоммиченных изменений.
Либо дропните незафиксированные правки либо создайте коммит с ними.
Иначе git не знает что с ними делать и выдал вам ошибку.

Коммитить напрямую в удалённый репозиторий невозможно, даже с паролем.
Наверное имелся в виду Push?
Для GitHub лучше сгенерировать персональный токен. Возиться с SSH не обязательно.
https://docs.github.com/en/github/authenticating-t...
Тем более с 13 августа 2021 пароли перестанут работать.

Сохраняем резервную копию базы в файл

mysqldump --user=USERNAME -p --default-character-set=latin1 -c --insert-ignore --skip-set-charset -r file.sql DATABASE_NAME

Преобразовываем в UTF-8

iconv -f utf8 -t cp1252 file.sql | iconv -f cp1251 -t utf8 | sed -e 's/latin1/utf8/g' > file-utf8.sql

Опустошаем базу

mysql --user=USERNAME -p --execute="DROP DATABASE DATABASE_NAME; CREATE DATABASE DATABASE_NAME CHARACTER SET utf8 COLLATE utf8_general_ci;"

Заливаем исправленную базу

mysql --user=USERNAME --max_allowed_packet=16M -p --default-character-set=utf8 DATABASE_NAME < file-utf8.sql

Как-то так

Прежде чем подключать новый, надо удалить ссылку на старый.
git remote remove origin
Затем добавляем ссылку на новый
git remote add origin https://github.com/...
Привязываем ветку к новому репозиторию
git push --set-upstream origin main

Это не версии, а защита от сбоев. Если Word завершится некорректно, мы тут увидим резервные копии документа, которые он сохранил в фоне.

На скрине видим что локально всё получилось. Осталось отправить это на сервер, но вы сможете это сделать только принудительно.
git push origin --force
Тогда указатель ветки origin/master тоже вернётся в "Initial Attempt".
Сами коммиты никуда не удаляются на самом деле. Вы их просто перестанете видеть, так как на них нет ссылок.
Окончательно они удалятся после "сборки мусора".