toxa82

Итоговый результат слияния кода при merge и rebase одинаковый. Разница будет только в порядке коммитов в истории. Merge сверху применяет новые коммиты, rebase находит общего предка, убирает ваши новые коммиты в ветке, обновляет ветку, применяет ваши новые коммиты сверху.

Результат у merge и rebase будет одинаковый. Разница будет только в истории.
Например git rebase master, убирает ваши новые коммиты в вашей ветке, обновляет вашу ветку до состояния мастера, и сверху накатывает ваши новые коммиты.

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

Вы правильно написали, можно даже просто uploads/avatars/
Но в папку нужно добавить файл .gitkeep, и добавить его в исключения игнора. Лучше так (универсально для всех .gitkeep) в конце файла .gitignore:
!**.gitkeep
Этот файл нужно будет запушить в репу. Git не пушит пустые папки.

Я не совсем понял что вы там навертели и зачем было использовать именно --hard. Но если вы коммитили изменения, то они остались. После хард-ресета они скорее всего уже не привязаны ни к чему и висят в ожидании уборки мусора. Моё решение не претендует на единственно верное, но можно попробовать.
1) С помощью рефлога git reflog --date=iso -20 посмотрите список где была HEAD в определенное время и найдите свои нужные коммиты.
2) С помошью git cherry-pick команды, примените указанные коммиты на нужной ветке.

git push -f
Но имейте ввиду что это перезатрёт ветку в удалённом репозитории вашей локальной веткой.

Вы бы написали командыскоторые выполняли. Если reset то попробуйте git reset --hard ORIG_HEAD

git push -f

reflog показывает где был HEAD. Чтоб посмотреть историю коммитов нужно использовать log