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

Много лет использую 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

Бесплатный 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 сможешь работать с этой веткой.