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

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

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

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

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

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


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

Может быть так сработает?

with open('f.txt') as file:
    lines = file.read().splitlines()

for line in lines:
    print(line)
    with open(line.encode('utf-8'), 'w') as file:
        file.write('')

Тут мы явно указываем, что имя файла в кодировке UTF-8, а не в однобайтной кодировке OEM.

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

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

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

Но ты можешь распаковать (checkout) разные ветки в разные каталоги (worktree). И уже для каждого сможешь сделать нужные настройки. Так ты получишь желаемое и пароли не придётся светить в публичном внешнем репозитории.

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

Бесплатный Issabel всё это умеет. Настраивается мышкой в веб-интерфейсе.
Если городской номер на аналоговой линии, то прикупить шлюз с FXO-портом. Если провайдер современный, то предоставляет доступ к номеру через SIP и шлюз не понадобится.
Если трубки аналоговые, то им понадобится шлюз с FXS-портами, но лучше сразу пользоваться IP-телефонами либо на обычные мобильники поставить SIP-клиент.

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

Не устанавливайте vmtools и драйверы виртуальных устройств. В настройке VM выберите эмуляцию реальных устройств если возможно. Vmvare умеет эмулировать стандартную сетевую карту E1000 и старенький IDE-контроллер. Видеокарта останется в vga-режиме. Всё будет жутко тормозить, но следов виртуализации на виду не будет ))

В настройках поменяйте вид.

Там в меню вашей 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 хеш_коммита -- полное_имя_файла
и состояние файла вернётся к тому, что было после коммита с указанным хешем.

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