¿Es una buena idea mantener proyectos separados en el mismo repositorio si están íntimamente relacionados?

Question

Estoy en las primeras etapas de una aplicación web que contendrá una aplicación de JavaScript del lado del cliente que se implementa en el navegador del cliente y una API de tipo REST del lado del servidor que residirá en mi servidor. Los dos se comunicarán usando los datos de Ajax y JSON.

Ahora aquí está la cosa; se están desarrollando completamente por separado, ni siquiera comparten una línea de código o un recurso. Ambas son aplicaciones node.js. El lado del servidor usa express y secuencial para todo lo relacionado con el servidor, y el lado del cliente se desarrolla usando el servidor de desarrollo de dobladillo con stylus y coffee-script y se compilará en 3 archivos (index.html, application.js y application.css).) que el servidor implementará en última instancia como datos estáticos.

La parte no estoy seguro de cómo controlar la versión de esto. Deberían tener números de versión compartidos o separados, por ejemplo. Además, ¿cómo debe verse el git repo? ¿Es común que una carpeta raíz de git repo contenga dos o más carpetas con proyectos separados pero íntimamente relacionados? ¿O debería separarlos por ramas, un servidor llamado, un cliente llamado? ¿O debería dividirlos en dos repositorios separados por completo? (Esto sería más costoso ya que estoy usando repositorios privados de github)

No estoy buscando a alguien que me diga qué hacer, pero infórmeme sobre los pros y los contras de las alternativas. En su experiencia, ¿cuál sería el mejor curso de acción y por qué? Por favor, siéntase libre de sugerir otros cursos de acción si cree que son buenos.

Gracias!

Answer 1

La regla general es, "las cosas que cambian al mismo tiempo deben ser versionadas juntas".

Si el backend necesita admitir varios clientes y cambiará independientemente de su interfaz, como lo haría si estuviera buscando una arquitectura basada en servicios, entonces vale la pena pensar en separar estas cosas en proyectos separados.

Sin embargo, dado que parece que estos dos proyectos estarán estrechamente relacionados, y su aplicación web solo tiene sentido con ambos en su lugar, le sugiero que empiece por mantenerlos en el mismo repositorio. Es una experiencia de desarrollo de menor fricción, y siempre puede dividirlos más adelante si resulta doloroso o si los equipos independientes deben trabajar en ellos.

Answer 2

Desde mi punto de vista, dividiría client y server en dos carpetas principales bajo root. Hay varias razones para esto:

1. Las versiones de cliente y servidor se relacionarán (físicamente) entre sí. Como lo hacen de todos modos porque su cliente estará estrechamente relacionado con la API proporcionada por su software de servidor. Entonces, si etiqueta el repositorio como versión, estará seguro de que ambos artefactos funcionan juntos sin problemas.

2. Tendrá menos dificultades para implementar pruebas de integración pesadas y desplegar una infraestructura de integración continua. Con las otras opciones, también es posible implementar esto, pero deberá proporcionar más sobrecarga.

uso de la rama general:

• el maestro se utiliza generalmente como una "instantánea" estable consistente de su aplicación (incluyendo clientes, servidores)
• una rama puede ser usado para representar una nueva desarrollo de características Por lo general, se usan de esta manera. Por lo tanto, puede terminar teniendo ramas 1..n que contienen adiciones a su software. Que se fusionará con tu maestro si te sientes feliz con él.

Answer 3

Ramas son para hacer versiones paralelas de una común base de código (véase "When should you branch").
Por lo tanto, no es una buena opción para realizar un seguimiento de dos módulos diferentes, pero estrechamente relacionados.

Los directorios simples dentro de su repositorio Git serán suficientes, y se asegurarán de que cualquier etiqueta que establezca en ese repositorio haga referencia a ambos módulos.