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

Да. Второй скрипт будет делать copy файлов из папки с резервными копиями, которые ты должен был предварительно создать.

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

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

Встроенными средствами Windows это пока не сделать. Нужны сторонние утилиты. Лет 20 назад мы использовали Partition Magic. Потом появились утилиты от Acronis. Но они больше не развиваются.
Сейчас безусловный фаворит — AOMEI. Там есть бесплатная версия в которой выполнишь команду Migrate OS to SSD. Утилиту можно установить в системе, либо использовать загрузочную флешку.

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

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

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

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

Много лет использую macOS и только сейчас узнал что такая замечательная функция тут тоже есть ))

Сначала пришлось узнать как её включить

defaults write -g ApplePressAndHoldEnabled -bool true

Ну а выключается соответственно командой

defaults write -g ApplePressAndHoldEnabled -bool false

Затем перелогиниться в системе.

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

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

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

Ошибка не при включении компьютера, а уже потом, при загрузке Windows.
Диск разбит в режиме MBR, а UEFI требует разметку GPT.
Перед тем как лезть BIOS, тебе надо сначала преобразовать диск в GPT.

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

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

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

Есть ещё третий тип людей, которые делают две резервные копии в разных местах и периодически проверяют их целостность. Это называется правило 3-2-1-0.

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

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

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

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

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