Vitsliputsli

Есть разные варианты даже в git-flow. В вашем случае, с учётом того, что вы делаете фичи, а затем выбираете, что пойдет в релиз (не очень понятно как вы формируете спринт при этом), ветка develop вам по-сути не нужна. Ветка develop предназначена для интеграции разных фич и проверки их совместной работы, в вашем случае это откладывается до финального тестирования релиза. Такой путь даёт гибкости, но может увеличить время финального тестирования, оправдан для несложных проектов и/или проектов с действительно слабым зацеплением, но даже в этом случае требуется постоянный контроль со стороны тимлида.

Либо привлекайте знающих товарищей по работе, чтобы на реальных примерах объяснили. Либо изучите git, там нет ничего сложного (для уровня "создал фичу - завершил фичу").
Трудно угадать в чем у вас проблема без текста ошибки. Что касается "чужих изменений", то делайте pull перед любой работой с удаленной веткой, и если там уже есть изменения, то делайте rebase вашей ветки в новый коммит.

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

Не привязывайте тестирование к веткам, а проводите его так как считаете нужным.
В принципе, у вас сейчас неплохой вариант, потому как все тестируется вместе, сможете выявить регрессии, которые бы не проявились по отдельности. В gitflow чаще всего так тестят ветку release. Но у вас, я так понимаю, rolling-releases? Тогда проводите тестирование фич отдельно, сразу же настройте сборку множества тестовых окружений, чтобы это не тормозило процесс, и скорость увеличится значительно.

Я не совсем понимаю как правильно написать коммит чтобы понятно было и мне и другим.

Что-то типа этого:
"PROJ-237. Добавлено описание продукта на странице 'О товаре'"
и если позволительно, то лучше на английском. PROJ-237 - номер задачи в вашей любимой системе управления проектами.

git-flow.
В своей ветке (feature) развлекаетесь как хотите, затем мержите в develop, а уже develop отправляете на сервер. В итоге ваша ветка вообще не попадает в репозиторий, только конечный итог.

push failed on refs/heads/master pre-receive hook declined
что с этим делать ?
я гуглил!!!! честно!!!! но не понял ничего

Да, ладно? Первая же ссылка в google предлагает обратиться к автору репа за разъяснениями почему настроенные им хуки отклоняют пуш, ну и заодно неплохо, когда хук возвращает причину отказа.
Возможно пуш вообще запрещен, только мерж, выясняйте у автора репа.

Избавьтесь от формы "выгружать в git", с git вы должны работать постоянно, а не выгружать в него. Сборка для тестирования должна быть такой же как для продакшн, иначе подобные ошибки будут вас преследовать постоянно. Автоматизируйте сборку, и не будет вопросов "деплоить после каждого чиха?".

Master = production, то что в master, то должно быть и в продакшн, не может быть никаких непроверенных коммитов в master, иначе это уже не master. Поэтому пересмотрите свою работу с git. И, как правильно замечено, прочитайте про gitflow, имхо, оптимальная система ветвления.

Раз вы работаете в Gitlab, то у вас уже есть инструмент для организации CI/CD.

1. Хорошая ли идея стягивать все исключительно по тегам т.е. поставил я на фронте и на беке тег v0.4 и скрипт на сервере стянул и то и другое

Нет, это не очевидно и усложнит работу, если репы разные, то и версионирование у них должно быть разное. Если вам нужна последняя версия, вытаскивайте сразу master. А для обновления подключаемого внешнего ПО используйте специализированные программы (тот же composer в php).

2. Самонаписанный скрипт постоянно чекающий теги гитлаба это вообще идея хорошая? В чем +\- деплоя по тегам?

А зачем постоянно чекать? В Gitlab есть хуки, если нужно какие-то действия осуществлять по push.

3. Как быть с адресами и портами. К примеру в index.js на девелоперской машине у меня прописано windows.base_url = "localhost:1234" а на сервере мне нужно "10.1.2.6:9000" как это это автоматизировать?

Все настройки должны быть в конфиге, при деплое конфиг настраивается в зависимости от среды. Можно сделать разные файлы для каждой среды, но все равно что-то придется менять конфиг при сборке (например, пароли к БД вы же не будете держать в репозитории).

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