Мені хотілося б знати, чи є сенс розділити проект, над яким я працюю, на два сховища замість одного.
З того, що я можу сказати:
- Frontend буде записаний у html + js
- Бекенд у .net
- Захід не залежить від фронтенду, а фронтенд не залежить від бекенда
- Фронтенд використовуватиме спокійний api, реалізований у бекенді.
- Frontend може розміщуватися на будь-якому статичному http-сервері.
На даний момент сховище має таку структуру:
корінь:
- передній / *
- бекенд / *
Я думаю, що помилка зберігати обидва проекти в одному сховищі. Оскільки обидва проекту не мають залежностей між собою, вони повинні належати до окремих сховищ та, якщо потрібно, батьківського сховища, що має підмодулі.
Мені сказали, що це безглуздо і що ми не отримаємо жодної користі від цього.
Ось кілька моїх аргументів:
- У нас є два модулі, які не залежать один від одного.
- Якщо історія джерел обох проектів у довгостроковій перспективі може ускладнити справи (спробуйте пошукати в історії щось на фронталі, тоді як у вас є половина комісій, які абсолютно не пов’язані з помилкою, яку ви шукаєте)
- Конфлікт та злиття (цього не повинно статися, але якщо хтось натискає на бекенд, змусить іншого розробника витягнути зміни в заднім часі, щоб підштовхнути зміни фронту.)
- Один розробник може працювати лише на бекенді, але завжди доведеться виводити передній або інший бік.
- Зрештою, коли прийде час розгортання. Якимось чином інтерфейс може бути розгорнутий на декілька статичних серверів, маючи один сервер резервного сервера. У кожному випадку, люди будуть змушені або клонувати цілий бекенд з ним, або виготовити спеціальний скрипт, щоб надіслати на всі сервери лише фронтенд, або видалити бекенд. Простіше просто натиснути / витягнути лише передній або резервний, ніж обидва, якщо потрібен лише один.
- Протилежний аргумент (одна людина може працювати над обома проектами). Створіть третій репо з підмодулем та розвивайте його. Історія зберігається відокремленою в окремих модулях, і ви завжди можете створювати теги, у яких версія синхронізу / фронтену дійсно працює разом разом. Об'єднання обох фронтенд / бекенд в одному репо не означає, що вони працюватимуть разом. Це просто злиття обох історії в одне велике репо.
- Якщо фронтенд / бекенд є субмодулями, це полегшить ситуацію, якщо ви хочете додати до проекту фрілансера. У деяких випадках ви не хочете надати повний доступ до бази даних коду. Наявність одного великого модуля ускладнить справи, якщо ви хочете обмежити те, що можуть "бачити / редагувати" сторонні люди ".
- Помилка введення та виправлення помилки, я вставив нову помилку у передній частині. Тоді хтось виправить помилку в бекенді. З одним сховищем відкат перед новою помилкою також відкатує бекенд, що може ускладнити виправлення. Мені довелося б клонувати бекенд в іншій папці, щоб сервер працював під час виправлення помилки у передній частині ... потім намагався перенести речі ... Наявність двох сховищ буде безболісною, оскільки переміщення ШОГИ одного репо виграло Я не міняю іншого. І тестування на різні версії бекенда буде безболісним.
Чи може хтось дати мені більше аргументів, щоб переконати їх або хоча б сказати мені, чому безглуздо (складніше) ділити проект на два підмодулі. Проект новий, а база даних коду - кілька днів, тому це не дуже рано виправити.