Во первых - не обязательно это должен быть git.
Есть треккеры с issue.
Git - следит за исходным кодом. Но возможно вам будет удобнее прописывать подробности именно в отдельном issue, а не в комментариях к коммиту в git.
Можно и совмещать.
Во вторых, полное руководство по git читать не обязательно.
По минимуму, достаточно даже двух команд:
git commit -a -m "Описание изменений"
git push
В третьих
Gitlab (и прочее свое ПО на свой сервер) ставить не обязательно. Они предоставляют услугу (даже бесплатную вроде) - по размещеню кода у них.
Так же подобную услугу предоставляет BitBucket (бесплатно), но функционал меньше чем у Гитлаба.
Также за небольшие денежки подобная услуга есть у GitHub.
В четвертых
При работе большой толпой лучше разделить репозитарии на отдельные по смыслу, а не работать в одной большой общей репе - по модулям, фронтенд, бекэнд и пр. и пр.
Хотя можно работать и в одной репе, но тогда придется больше уделять внимания слияниям.
При работе в одного - одного общего на все модуля (фронтенд, бекэнд) репозитария достаточно.
В пятых
По умолчанию организация работы в git как раз и предполагает, что репы живут в двух ипостасях - удаленная на сервере и локальная.
В шестых
Тестовая для показа и итоговая для выгрузки на боевой сервер можно решать ветками.
Традиционно ветка называемая "master" - это основная (боевая).
В седьмых
GitLab довольно тяжеловесен и требователен к серверу
Если уж хочется нечто похожее на свой личный GitLab то имеет смысл посмотреть
на
https://habrahabr.ru/company/selectel/blog/305422/
В восьмых
Графические клиенты для git (SourceTree) вам вряд ли понадобятся - они полезны разве что
если у вас будет очень много веток и их объединений. Да и то - возможностей у Gitlab для визуального наблюдения изменений довольно много.
Средний
Простой
