Папка против хранилища в github
Я новый пользователь https://github.com/ и пытаюсь создать мобильное приложение, состоящее из двух частей: кода клиента и кода сервера. Код клиента будет написан на Java для Android, Swift для iOS и C# для Windows Phone. Серверная часть будет написана на PHP, HTML, Javascript и CSS.
У меня такой вопрос: как мне структурировать код? Должен ли я поместить серверный код и код клиента в разные репозитории или просто поместить их в разные папки в одном репозитории? Кроме того, поскольку существует несколько клиентов (Android, iOS и Windows), следует ли размещать их в разных репозиториях или в разных папках?
Я уже знаю, что любой из них можно сделать, но я хочу знать, что такое стандартная процедура и каковы ее преимущества / недостатки.
Есть много возможных решений этой проблемы. Ответ, предоставленный saljuama, является наиболее полным.
Посмотрев несколько проектов на github, я обнаружил, что один из способов сделать это - создать отдельные репозитории для клиента и сервера. Если у вас есть несколько клиентских кодов (как в моем случае), вы можете использовать один и тот же репозиторий, но разные make-файлы.
Я нашел этот способ сделать что-то на https://github.com/CasparCG. Сервер - это другой репозиторий, чем клиент. Кроме того, клиенты используют одни и те же папки src, lib и другие, но сценарии сборки каждой из них различны. Как отмечает saljuama, этот метод имеет смысл, когда ваши клиенты используют одну и ту же кодовую базу. Если ваши клиенты не используют одну и ту же кодовую базу, смотрите ответ saljuama.
Это не единственный возможный способ. Вы можете сделать это по-своему.
1 ответ
Тема довольно обширная и может быть основана на мнении, но я постараюсь оставаться максимально нейтральным.
Согласно основному принципу кода12factor, каждое приложение должно иметь свою собственную кодовую базу (или хранилище). Поскольку клиент и сервер - это разные приложения, они не должны использовать одно и то же хранилище.
Одной из причин, по которой наличие обоих в одном репозитории является плохой идеей, является использование систем непрерывной интеграции и непрерывной доставки. Поскольку принудительное включение этих процессов обычно инициируется нажатием на репозиторий, изменение на одной из сторон заставит сервер CI/CD обрабатывать обе стороны приложения, когда в этом нет необходимости.
Остальные причины, которые я могу придумать, могут быть отнесены к категории основанных на мнении, поэтому я не буду их приводить.
Обновление:
Чтобы ответить на обновление вашего вопроса, если разные клиенты имеют одинаковую кодовую базу, если вы продолжаете читать о принципах, конфигурации и сборках приложений с 12 факторами, вам следует использовать один репозиторий.