Вячеслав Плиско

компосер лучше истанавливать из lock файла через composer insatall, без update, чтобы версии совпадали, а то мало ли в новых регрессии.

т.к. вас нет .env на сервере то нет и ключа для encrypter. нужно создать .env файл и выполнить
php artisan key:generate

и права на запись вебсерверу выставить на storage и bootstrap/cache

laravel.com/docs/5.1#installation

В коммит кодируется информация о номере таска и его название. Ваш пример хорошо подходит на commit ---amend, для этого и нужны ветки, чтобы опечатки не фиксить отдельным коммитом. Я в целом стараюсь придерживаться по возможности правило — один таск, одна ветка, один коммит и amend позволяет не размазывать логику по коммитам.

гит здесь не при чём, у вас банальные зависимости, в мире php это решает через pear или composer, в других языках есть свои пакетные менеджеры. каждый пакет хранится в своём репозитории и имеет лишь файлик, прописывающий зависимости.

А вы IDE не пользуетесь, у них локальная история есть, оттуда прекрасно всё достаётся, самого пару раз спасало от случайного удаления.

Не-не-не. Вы совсем не туда думаете.
Каждая фича в отдельный бранч и желательно в нём всего один коммит, апдейты делаются амендом, это позволит легко тягать ваши коммиты черри пиком вместо мержа, что особенно удобно когда ведётся несколько стабильных релизов.
Соотвественно разработчик пушит всё в свой репозиторий, делает пулл реквест. Затем собирается билд посредством мержа основного репозитория и ветки из репа разработчика. Если всё ок, то принимаем пулл реквест. Дальше ветки разраба никому не мешают, могут и полежать. Оснвной реп относительно чист.

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

Ни в коем случае не делайте всего две ветки, в гите же бранчевание элементарнейшая и приятнейшая вещь.
Нужно иметь две основные ветки — stable, current. В первой стабильный билд, а в current последние вмерженные пуллреквесты до поры пока не решете что current стабилен, затем они мержатся в stable, тестируется, делается тег.
Вы вроде используете аналог гитхаба gitosis.
Выше был описан главный репозиторий, назовём его upstream.
У каждого разработчика свой репозиторий на сервере (назовём origin), он бранчуется от ветки main/current, вносит изменения (мы стараемся делать это одним коммитом, для правок --amend), когда готово пушит ветку в origin на gitosis, делает пулл реквест в upstream.
Обязательно второй программист делает ревью, проверяет что ничего не сломано и лишь затем он же нажимает кнопку впулить.

Билд же для продакшена собирается ant или copistrano, из тега, максимум из stable.

Забейте, вам git не нужен. Тем более в вашем случае прекрасно можно пользоваться external из svn, который можно эмулировать лишь костлями в гите. Да и версия у вас плоская, так что все плюсы бранчевания и мержа не скажутся.
Если я не ошибаюсь, то нынче свежий svn хранит всё так же как и git в одной папке в корне проекта, так что в этом плане тоже разницы нет.