Дмитрий

Достаточно просто создать временную ветку на конце той, которую вы собираетесь исправлять

git checkout branch_name
git checkout -b temp

После этого можете делать с branch_name все что угодно. temp не даст коммитам пропасть. Ну а потом git cherry-pick всего, что нужно в исправленную ветку или в любую другую.

Вы видимо один работаете над проектом?
Сделайте rebase (описание процесса), а потом
git push -f

Положите .gitignore в эту папку.

Самый простой вариант - git-ftp (https://github.com/git-ftp/git-ftp)

Сделайте линк в обратную сторону - из конечной точки на папку внутри гит репозитария.

Git-ftp именно то, что вам нужно.
https://github.com/git-ftp/git-ftp

Создавайте коммиты в стиле:
"Клиент - Описание"
"Сервер - Описание"
Я всегда так указываю модуль проекта, в котором делал изменения.
Кстати, с помощью git log -- path/to/backendFolder можно увидеть, в каких коммитах были одновременные изменения клиента и сервера.

Вы можете начать пользоваться git и при этом продолжать заливать файлы по ftp.
Установите расширение https://github.com/git-ftp/git-ftp и вы сможете push'ить свои изменения через ftp. Копироваться будут только измененные файлы.
Установка и использование тривиальны: https://habr.com/post/178067/
Только имейте в виду, что на сервере не будет полноценного git-репозитория - только файлы, поэтому если у вас накроется локальный, то клонировать будет неоткуда.

Варианты есть. Я придумал вот такой, довольно экстравагантный:

$ git checkout F1
$ git reset --hard HEAD^ (первые две команды можно заменить на git checkout -B F1 C3)
$ git commit –am “C10”
$ git checkout F3
$ git rebase F1
$ git cherry-pick C4
$ git checkout -B F1 C4

И все ветки будут на своих местах.
Скажете, что я на втором шаге удалил C4... ну да, удалил! ;) Только это ничего не меняет, все будет работать.
Просто нужно помнить что удаляя коммиты и двигая ветки вы в реальности ничего не удаляете (если, конечно, не запустите сборку мусора). Т.е. мы, например, легко можем восстановить утерянные коммиты C8 и C9 если выполним
$ git checkout -b test C9
Ну а если вы уже забыли что именно удалили, то git reflog вам в помощь.

Рекомендую откатиться назад и удалить этот коммит. После чего залить изменения на сервер git push -f.
Затем все разработчики должны будут сделать следующее (для сохранения уже сделанных локальных коммитов):

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master

После этого с помощью git cherry-pick нужно перенести свои локальные коммиты в master.

PS: Имейте в виду, что если вы сейчас не избавитесь от этих больших файлов, то они останутся там навсегда и даже git revert не вычистит их из репозитория.

Каждый начинающий git'er должен знать про команду git reflog, т.к. если что-то поломал, то reflog всегда спасет! :)

Если вы форкаете проект на GitHub, то и описание стоит поискать там же...
https://help.github.com/articles/fork-a-repo/
все давно расписано по шагам.
Ну или вот, частично переведено на русский:
https://git-scm.com/book/ru/v2/GitHub-%D0%92%D0%BD...

Кратко про GitHub:
1. Делаете fork и клонируете форкнутый репозиторий к себе на комп.
2. Чтобы обновить свой форк нужно локально сделать fetch с оригинального репозитория, а потом сделать push в свой форк.
3. Чтобы обновить оригинальный репозиторий, делаете локально новую ветку, в которую комитите все изменения. Пушите ее в свой форк, а затем на сайте создаете Pull Request. Хозяин оригинального репозитория должен принять ваши изменения.

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

Если содержательность сообщений вас не устраивает, то вы можете всегда сделать git rebase -i и их переименовать, или даже слить что-то вместе. Естественно это нужно делать до git push

Сначала находите коммит, в котором файлы еще есть (в вашем случае можно использовать, upstream/master). Затем:
1. Визуализируете список измененных файлов (grep'ом фильтруем только удаленные)
2. Восстанавливаете нужные файлы из коммита
Далее делаете новый коммит, пушите в репозитарий и т.п.

git diff --name-status upstream/master | grep ^D
git checkout upstream/master <path/to/the/deleted/file>

Черипики - это, конечно, удобно, но может привести к неприятным последствиям. Это во-первых дублирование коммитов, а во-вторых, если забыть что-то черипикнуть, то ваш клиент перестанет работать и вы будете долго разбираться что к чему.

Решения два:
1. Если ваша ветка client - просто усовершенствование ветки master, то можно сделать rebase и переместить client на верх master'а. Это меняет историю, поэтому подходит не всем, но если вы работаете с репозиторием в одиночку, то вполне нормальное решение (история будет красивой).
2. Так вам и не нужно мержить client в master, а как-раз наоборот смержите master в client и будет именно то, что вам необходимо.

Хм... я бы попробовал так:
Назовем последний имеющийся коммит (0), а текущую ветку (а).
Поскольку сделана stash apply, то в стеше этот элемент сохранился (если pop, то нужно поколдовать с git reflog).
1. Сделаем коммит (1а).
2. Вернемся к коммиту 0 и создадим ветку "б"
3. Выполним git stash apply в ветку "б"
4. Сделаем коммит (1б)
5. Сделаем git revert предыдущего коммита (2б)
6. Перейдем в ветку "а" и сделаем git cherry-pick 2б (получим коммит 2а)
7. Если все нормально, то объединяем коммиты 1а и 2а (git rebase -i)
Все.
На словах довольно просто, но в реальности это может усложниться конфликтами, но они решаемы.

На мой взгляд, делать постоянно amend, как предлагает выше Борис, идеологически не верно. Главное предназначение git - возможность сделать быстрый откат или найти коммит на котором что-то сломалось.
Лучше делать много мелких коммитов, а после тестирования объединить их в один с помощью
git rebase -i

Вообще, делать пробы лучше в отдельной ветке - так гораздо меньше головняков...
Если пробы все-таки хочется сохранить (хотя бы временно), то можно сделать так:
Итак у вас есть коммит аааааа (последний - о котором вы пишите) и есть коммит сссссс. Пробные коммиты находятся как-раз между аааааа и сссссс. Ветка master, по вашему описанию, находится на самом верху, т.е. на аааааа.
1. Создаем тестовую ветку: git branch Tests (теперь на аааааа две ветки)
2. Переносим master на последний полезный коммит: git reset --hard cccccc
3. Копируем нужный коммит: git cherry-pick аааааа
4. Отправляем master: git push -f
Посмотреть ситуацию наглядно можно так: git log --oneline --decorate --all --graph
Все. Пробные коммиты остались в отдельной ветке. Ее можно удалить. А если они все-таки нужные и там предполагается продолжит работу, то нужно сделать rebase:
5. git checkout Tests
6. git rebase master
Тестовая ветка передвинется на топ master'а а коммит aaaaaa пропадет, т.к. он уже есть внизу.

ЗЫ: Чтобы не писать длинно git log (это очень частая команда), советую сделать alias.