Vitsliputsli

Можно. Но, например, когда проект начнет работать вам понадобится добавить новую фичу, а следовательно у вас появится 2 версии и нужно будет их как-то легко разделять. Пока вы будете делать эту новую фичу, нужно будет сделать еще одну побыстрее, уже 3 версии. Можно наделать отдельные директории и переключаться между ними, использовать внешние утилиты сравнения, а можно использовать git.
Когда через год понадобится разобраться, а зачем так было сделано, можно найти коммит, в рамках которого было внесено изменение и понять зачем. Еще лучше, если коммиты связаны с тасками в системе управления проектом.
Когда наскучит вручную таскать код на сервер. Когда устанешь копировать файлики между версиями для переноса функционала. Когда все сломал, и понимаешь, что легко бы нашел причину, если бы фиксировал предыдущее стабильное состояние. И это только то, что первое приходит в голову.

В чем может быть проблема?

Написано же: Host key verification failed.

Как можно поправить конфликты PR, чтобы лишние коммиты не попадали в develop?

Не коммитить лишнее в develop. Удалите лишний коммит.

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

У gitflow есть разные варианты реализации, но чаще всего да, подразумевается создание из dev. Причина проста: dev - это ветка разработки, там уже могут быть реализованные фичи, которых еще нет в master, лучше сразу начать разработку с более новой версии, чем потом решать конфликты при мердже.

git submodule

master - только для стабильного кода, который уже работает на проде.
Новую разработку ведите в другой ветке (например, dev). Как стабилизируете и проверите код в dev, мержите его в master.
На следующем этапе разработку в dev разбивайте на отдельные feature, там уже можно посмотреть что-нибудь вроде git-flow.

1)

мне хочется, чтобы после исправления бага, новый коммит проходил проверку QA, но как организовать стейжинг пространство в этом случае? Слить код в нестабильный девелоп и выкатиться на стейжинг мы не можем, поскольку изменения девелопа могут нестабильно сказаться на релизе№1. Как быть?

А в чем проблема? Отдайте hotfix в QA пусть проверяют. Как в случае feature QA тестирует ветку release-..., так и в случае hotfix, QA тестирует ветку hotfix/... .

2)

откуда разраб должен отпачковываться в данном случае, от девелопа или от ветки с фичой №1?

Если фича №1 зависит от фичи №2, а в dev фича №1 отсутствует, то очевидно, что от ветки фича №1, других вариантов я не вижу.

3)

Согласно agile вторая команда, работающая над фичой№2 не может отправлять свой код в девелоп, иначе это замедлит поставку нового релиза

Наверное agile здесь не при чем. Если работаете по scrum, то каждый спринт это подготовка нового релиза и вы не можете работать над фичей не из этого релиза. git-flow ориентирован именно на такую работу.
Если релизы плавающие, я так понял у вас так, значит не сливайте фичи не из текущего релиза в ветку из которой готовите релиз. Если не выходить за рамки git-flow, то не сливайте в dev ветки не из текущего релиза, QA пусть тестирует либо feature, либо по тегам, если работаете с pull-request, то апрувьте их, но не делайте merge.

Из всего выше описанного, мне кажется у вас 1 единственная сложность, это вопрос как должны работать QA.

Либо добавляемая директория идентична предыдущей, либо она в игноре.
Директории отличаются? Что в .gitignore? Что пишет git status?

Лучше, конечно, сразу на будущее поставить gitlab. Но в принципе, можете обойтись git и хорошим клиентом к нему (в первую очередь для diff). PHPStorm вполне достаточно. Для code review не так уж и нужны доп.инструменты. Даже не заморачивайтесь pull request, отдельных веток и мержа их в dev вашими силами вполне достаточно.