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

Изменить нельзя, но можно пересоздать коммит, в том числе с новым сообщением.
Последний коммит ветки через git commit --amend
Более ранние через git rebase --interactive

И чтобы изменения кода показывал не в двухоконном режиме, а в одной области (красным - удалённые, зелёным - добавленные)

Для этого и клиент не нужен, в консоли так показывает. Разве это удобно?

А вообще SmartGit однозначно лучший и денег не просит.
И не стесняйся использовать возможности твоей IDE. Автономные клиенты не понимают синтаксиса языка более корректного разрешения конфликтов.

В 2022 году наверное можно пользоваться sparse-checkout

Вернуть один файл к состоянию, которое было в коммите
git restore <хеш_коммита> -- file2

Можно через GitHub CLI

1. Клонировать себе на комп git clone
   
2. Поменять автора коммитов используя git filter-repo
   
3. Отправить в новый пустой репозиторий git push -all <URL_нового_репо>
   

git filter-branch заявлен устаревшим и небезопасным

modified:

Это означает что файлы уже добавлены в репозиторий и отслеживаются.
А gitignore имеет смысл только для неотслеживаемых файлов, т. е. которые ещё не добавлены и мы не хотим их добавлять. Удалите файлы из репозитория и увидите, то игнор работает.

Push обновляет ТОЛЬКО в репозиторий, но сама рабочая папка с файлами остаётся нетронутой. Чтобы она обновилась, нужно на сервере актуализировать её вручную
git reset --hard

Файл удаляется, потому что история содержит коммит с его удалением.
Чтобы не потерять файлы на других серверах, обновляем их немного хитрее.

git fetch # загрузить обновления репозитория
git switch master # проверяем, что мы в нужной ветке
git reset origin/master # переместить HEAD на актуальное состояние
# сам рабочий каталог при этом не изменится, 
# так как по-умолчанию используется режим reset --mixed
git reset --hard # теперь можно актуализировать рабочий каталог
# файлы указанные в .gitignore не изменятся и не удалятся

Проверьте в настройках параметр show_git_status

git reset --hard приведёт состояние проекта в рабочем каталоге в соответствие с HEAD

Если отменить изменения файла и закоммитить, то он исчезнет из PR
git restore <FILE> origin/target_branch

Попросить гит временно не замечать изменений в файле config_file.
git update-index --assume-unchanged config_file

Вы внесли изменения только в репозиторий, но не актуализировали сам рабочий каталог репозитория, в котором лежит сайт. git status вам об этом и сообщил.
Очистить рабочий каталог от ненужных изменений можно командой
git reset --hard
Согда файлы синхронизируются и репозиторием.

Этот вопрос — прекрасная иллюстрация того, какие только костыли готовы изобрести адепты 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. Сделать целевой репозиторий голым, но тогда вы не сможете в него коммитить напрямую.