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

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 перед тем как копировать файлы на флешку?) и потом так же очисти рабочий каталог и запиши изменённый проект на это место.

Ты в общих чертах описал рабочий процесс git-flow, но rebase там неуместен, синхронизация делается исключительно через merge, так как ветки master и dev долгоиграющие.
Погугли. На эту тему много хороших статей, но не факт что вашей компании такая модель идеально подойдёт.
Такие вопросы решаются до начала разработки обычно, так как схем ветвления можно придумать много и не существует единственно правильной.

А судя про то, что пишешь про комментирование кода чтобы временно скрыть и про перебазирование для синхронизации — ты похоже не понимаешь зачем нужен и как работает Git.
Почитай документацию или посмотри Git-курс на Ютубе.

Желтая бирка означает что ты сейчас не находишься ни в какой ветке (состояние отсоединенного указателя HEAD). Что ты собрался запушить? Ветка же нужна, которую пушить. HEAD это не ветка, это просто указатель на текущее состояние. Вот хороший мультик, который поможет тебе понять что происходит.

Тебе надо установить указатель твоей ветки на текущий коммит, на который указывает HEAD
git checkout -B имя_твоей_ветки HEAD
Тут важен регистр опции -B, так как ветка с таким именем уже где-то существует и мы принудительно пересоздаём её на новом месте. А находясь в ветке, мы уже сможем её запушить.

Это называется не добавить, а распаковать ветку в рабочий каталог из локального репозитория (сделать текущей), в который она уже загружена (добавлена) командой fetch.
git checkout -b develop origin/develop --
И всё. После checkout сможешь работать с этой веткой.

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

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

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

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

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

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

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

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

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

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

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