Как уже написали стоит использовать системы контроля версий. Например Git. Если нужны бесплатные приватные репозитории, то можно пользоваться gitlab или bitbucket.

Лично я дома использую следующую схему:
На сервере гипервизор esxi. Одна из виртуалок gilab-ce. В другой виртуалке развернул jetbrains youtrack. В проектах youtrack настраиваю синхронизацию с репозиториями из gitlab.
В качестве IDE использую phpStorm, в котором настроена синхронизация задач с youtrack.

Когда проект приходит в работу:
1) Создаю репозиторий в gitlab.
2) Создаю проект в youtrack
3) Настраиваю в youtrack синхронизацию с репозиторием
4) В youtrack нарезаю проект на задачи
5) На рабочей машине создаю проект в phpstorm и настраиваю в нем синхронизацию задач с youtrack.

Дальше при работе над конкретными задачами в phpstorm ставлю выполнение тех или иных задач, через tools->Tasks&context

А теперь для чего все это нужно:
Иногда встречаются повторяющиеся задачи, но тяжело вспомнить в каком проекте они реализовывались. А так в результате всех этих манипуляций, я имею историю работы над всеми проектами в yotrack. Причем сразу видно описание задач, в которых можно отследить какие изменения в код вносились по той или иной задаче. Например вот так это может выглядеть https://yadi.sk/i/WER-B7yB3L5ybN . Теперь почитав описание задачи, можно открыть вкладку VCS и сразу перейти в коду.

Тут можно почитать про связи между ORM сущностями.

Если сущности, о которых вы спрашиваете, связаны, то делается это довольно просто.

Допустим вот так описано поле по которому идет связь между сущностью Book и Author внутри класса BookTable:

new Entity\ReferenceField(
    'AUTHOR',
    'SomePartner\MyBooksCatalog\Author',
    array('=this.AUTHOR_ID' => 'ref.ID'),
    array('join_type' => 'LEFT')
)

тогда чтобы выбрать какое либо поле из сущности author надо в getList добавить Author.<Код поля>. например так:

BookTable::getList(array(
    'select' => array(
        'TITLE',
        'AUTHOR_NAME' => 'AUTHOR.NAME',
        'AUTHOR_LAST_NAME' => 'AUTHOR.LAST_NAME'
    )
));

Пример взят из статьи по ссылке приведенной выше.

Я предполагаю что мы делаем бэкап на тестовом сайте и переносим его на боевой и там уже восстанавливаем, прав ли я, если нет то подскажите как сделать это?

Зависит от сайта и изменений.

• Изменения только в коде и в базе ни чего не изменялось? Тогда вообще стоило бы их через git накатывать.
  
• Изменения как в коде так и в базе:
  
  • Если на сайте не было за это время изменений, то может прокатить развёртывание бекапа.
    
  • Если же сайт активно использовался: создавались заказы, редактировались товары, сделки в Б24 и т.д, то такой вариант не уместен так как будет потеря данных. В таких случаях нужно использовать миграции. Есть много разных вариантов написания миграций, но общая суть в том, что изменения в БД фиксируются в виде скриптов, которые выполняются в момент деплоя. Один из способов управлять миграциями- это модуль sprint.migration.