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

Этот вопрос — прекрасная иллюстрация того, какие только костыли готовы изобрести адепты Mercurial, только чтобы не пользоваться удобным и логичным Git. В Git синхронизация между разными рабочими компами это привычный и предельно простой процесс, использование облака тут выглядит бредово.

Разница идеологий. Если Git это инструмент, помогающий создавать качественный код, то Mercurial является лишь инструментом фиксации уже готовой работы и эту самую работу над кодом лишь усложняет. А если какой-то мусор попал в репозиторий, то это навечно. Придётся смириться со случайно закоммиченным тяжелым файлом и заставить скачивать его всем коллегам, так как история «священна» и не подлежит переписыванию.

Никакие коммиты перемещать не нужно. Они уже часть ветки task автоматически, так как являются родителями её коммитов. Единственное что потребуется в такой ситуации — откатить указатель ветки master на два коммита назад, раз мы работали там по ошибке.

git switch master
git reset --hard HEAD~2

git init 
git remote add origin https://bitbucket.org/username/reponame.git
git fetch # собственно скачивание репозитория
git reset origin/master # поставить указатель в нужное место
git branch -u origin/master master # настроить связь веток

Без скачивания, репозиторий не появится локально. Рабочая папка с текущим состоянием проекта это не репозиторий.

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

Но проще использовать ссылку https, чтобы не возиться с ключами.

git init # инициализировать репозиторий в папке тестового проекта
git remote add origin <URL> # указать адрес вышестоящего репозитория
git fetch # скачать вышестоящий репозиторий
git reset origin/master # установить указатель на ветку master
# существующие локальные файлы в рабочем каталоге измениться не должны
git branch --set-upstream-to=origin/master master 
# связать master с origin/master

Вы делаете почти правильно

git fetch origin
-- ошибок не выводит, но и результата никакого не даёт

Потому что вы ранее уже сделали pull, который включает в себя fetch
Если ничего не выводит, значит ошибок нет и изменений в origin тоже нет.

fatal: 'origin/master' does not appear to be a git repository

Гит говорит, что origin/master не является корректным адресом репозитория.
Правильный синтаксис: git pull origin master

И не называйте пожалуйста GitHub гитом.

Вопрос поставлен слишком абстрактно. Толком не понятно что требуется сделать и с какой целью. Слишком много ситуаций можно придумать под эту формулировку.

Лучше почитайте базовые руководства, тогда поймёте как гит работает и перестанете задавать такие простые вопросы.
Начните отсюда https://githowto.com/ru
Потом потренируйтесь https://learngitbranching.js.org/?locale=ru_RU

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

«Пушить локально» это масло масляное. Мы всегда пушим локально, но во внешний (remote) репозиторий. Понятия внешний и локальный тут относительны, так как все репозитории в Git равноправны и могут обмениваться коммитами в любых направлениях. Причём репозитории запросто могут лежать на локальном компьютере. Репозиторий откуда мы выполняем команды push/fetch/pull называется «локальным», а тот откуда/куда передаём данные называется «внешним». Я не люблю перевод слова remote как удалённый, потому что потом возникают дикие конструкции типа «удалить удалённый», которые ломают мозг.

Выибивает ошибку что non-bare репозиторий.

Вы невнимательно читаете текст ошибки. Там ключевое слово current branch in a non-bare repository, т. е. нельзя пушить в текущую ветку, которая в данный момент распакована в рабочем каталоге. В голом репозитории (bare) нет рабочего каталога, поэтому такой проблемы не возникает.

Как правильно синхронизировать ветки репозиториев? Способов много
1. Перед push зайти во «внешний» репозиторий и переключиться в другую ветку.
2. Вместо push из «локального» репозитория можно делать pull, находясь во «внешнем».
3. Можно заставить Git игнорировать проблему, но рабочий каталог «внешнего» репозитория просто не будет актуализироваться сам, нужно будет потом там вручную делать git reset --hard
4. Сделать целевой репозиторий голым, но тогда вы не сможете в него коммитить напрямую.

Репозиторий нужно создавать ВНУТРИ каталога с проектом, а не в корне профиля пользователя.

вместо нормальной структуры папок в удаленном репозитории: proj/файлы проекта

Это вовсе не нормальная структура. Сама папка proj не должна отображаться в проекте.

Git работает ровно так, как и должен. Всё запушилось в репозиторий, но если вы хотите актуализировать рабочий каталог тоже, то это придётся сделать командой
git reset --hard HEAD

Либо не обращайте внимания на рабочий каталог, либо сразу инициализируйте репозиторий на сервере в режиме bare, т. е. без рабочего каталога. Именно так работает GitHub или BitBucket
git init --bare

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

git rm "delete_file_old/*"
git commit --amend

Если добавили в старых коммитах, то через git filter-repo

git rm "путь/import_1*.csv"

А вообще, никогда не было проблем с именами в юникоде, даже в Windows.
Но я предпочитаю отключать экранирование при выводе
git config --global core.quotePath false

И работать проще в SmartGit, чем в голой консоли. Особенно если файлы с русскими именами, да ещё в какой нибудь древней кодировке Windows-1251.

У вас сбились связи между локальными и внешними ветками. Я не нашел как починить это через интерфейс JetBrains, но оно легко чинится через терминал.

➜ git branch -vv
* main 0e02250 [origin/dev] Commit Message

➜ git push -u origin main:main
branch 'main' set up to track 'origin/main'.
Everything up-to-date

➜ git branch -vv              
* main 0e02250 [origin/main] Commit Message

Чтобы PhpStorm увидел изменения, наверное придётся его перезапустить.

Первый способ


Второй способ

Пересадить ветку в новое место
git rebase --onto develop master feature

Если понимать, что ветка это не какая-то коробочка с коммитами, а указатель на некоторое состояние проекта на дереве, то мы просто устанавливаем указатели веток в нужные места. Никакие коммиты перемещать не надо, они то как раз уже на своих местах.

git branch feature/menu # создать ветку, новые коммиты уже окажутся в ней
git reset HEAD~5 # откатить мастер на 5 шагов назад

Чтобы файл не пушился во внешний репозиторий, не коммитьте его в локальный репозиторий.

8.1 Настройка Git — Конфигурация Git

git config --system receive.denyNonFastForwards true
git config --system receive.denyDeletes true

Tailscale — позволяет поднять туннели до любых устройств за шлюзом.
Множество компов в разных подсетях объединятся в одну виртуальную сеть.
Поддерживает macOS, Linux, Windows, Android, iOS. Используется движок WireGuard.
Быстрый и нетребовательный к ресурсам. Для личного использования бесплатно.
И что самое удобное, не требуется ничего пробрасывать на роутерах и работает с динамическими IP.

Если

неверно ввел логин и пароль

Удалить ошибочную авторизацию можно командой

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

Нельзя восстановить файл, если вы его как минимум не индексировали. Если удалённый файл индексирован, но ещё не закоммичен то git restore :/ вытащит его из индекса. Если файл уже закоммичен, то простой git restore -- file его восстановит уже из репы.

Если вы называете сервером тот компьютер куда загружаются коммиты с "гита", то нет, пропустить коммиты при pull нельзя.
Чините гит , запустив git rebase --interactive HEAD~2 на компе, который вы назвали гитом.