Я бы сказал, что лучше хранить их в двух разных репозиториях. Если бы это было настольное приложение, написанное, например, в электронном виде, то, возможно, использование двух папок было бы более эффективным, но в вашем случае я бы определенно выбрал два репозитория. Кроме того, будет проще поддерживать кодовую базу без конфликтов с совершенно несвязанным кодом. Что касается использования веток, я бы предложил эту небольшую статью, чтобы понять их назначение.

Удачи.

Одно и то же репо и 2 разных филиала не приносят никакой добавленной стоимости.

Итак, это либо:

• 2 разных репозитория
• или 1 репозиторий, а также обратный и передний код в одной и той же ветке, называемой стратегией «монорепо».

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

Но это повлияет на ваш процесс развертывания/упаковки: вам необходимо выяснить, облегчит ли размещение всего в одной ветке развертывание (развертывайте все одновременно) или усложнит, если вам нужно собрать 2 пакета и провести тестирование качества. обоих.

Определенно не размещайте их в ветках. Ветки предназначены для одновременной работы с одним и тем же контентом, а не для хранения совершенно другого контента.

Учитывая это, все зависит от того, хотите ли вы запустить это как один проект или как два.

Одно репо

Одно репо проще. Вам не нужно координировать изменения и выпуски между фронтендом и бэкендом. Если у вас есть ошибка или функция, ее можно закодировать, протестировать и выпустить в одном проекте.

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

Два репозитория

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

По сути, серверная часть будет зависеть от внешней части. Для использования внешнего интерфейса потребуется четко определенный API. Это может быть хорошо, поскольку в этом случае серверная и клиентская реализации будут разделены, но это требует затрат.

Что использовать?

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

Вы всегда сможете разделить его позже, однако распутать его будет сложнее.