El número y tamaño de sus archivos está dentro de la capacidad de git para mantener todo eso como un repositorio. Incluso si los subiste por una orden de magnitud o dos. Entonces, las verdaderas razones para dividirlas en dos repositorios, o mantenerlos en un solo repositorio, tienen que ver con la facilidad de uso, no con los límites técnicos de git.
Me gusta mantener las pruebas en el mismo repositorio que el código que prueban. Cuando actualizo el código para incluir nuevas funcionalidades, actualizo las pruebas unitarias, y es bueno tener las dos sincronizadas.
Cuando agrego el código para corregir un error y agrego una prueba de regresión teniendo los dos en sincronía, vuelve a ser agradable.
Con la unidad y las pruebas de regresión sincronizadas con el código cuando reviso una revisión anterior, sé que todas las pruebas incluidas deberían pasar. Cualquier falla que pueda atribuir a algún otro componente en el sistema (digamos un cambio de sistema operativo o herramienta), que me ayuda a señalar ese tipo de cosas sin interferencia al adivinar qué pruebas podrían ser "fallas esperadas".
El inconveniente es que si noto que falta algo en las pruebas de mi unidad, no es fácil agregarlo retroactivamente a donde debería haber estado. Sin embargo, encuentro una desventaja más pequeña que tener muchas fallas de "supongo que podría estar bien" cuando verifico si el código del último abril funciona con algún subsistema nuevo u otro.
Sin embargo, sus compensaciones pueden ser diferentes. Tal vez su cadena de gestión no brinde suficiente soporte para que se agreguen extensas pruebas de unidades a medida que se agreguen nuevas funcionalidades, por lo que es posible que tenga un mayor porcentaje de pruebas que quiera aplicar retroactivamente. Tal vez sea mejor exportar cambios de funcionalidad a través de algún atributo legible y sus conjuntos de prueba simplemente no pueden ejecutar fallas esperadas. Tal vez sus pruebas sean administradas por un grupo diferente luego del código. Cualquiera de ellos podría cambiar el equilibrio.
Parte de mi 'problema' era también la necesidad de copiar y mover directorios a una nueva estructura de archivos. Y luego haz que Git recoja los cambios de la manera correcta. –
Necesitaba actualizar mi.gitignore y limpie la memoria caché de índice para detener el seguimiento de algunos archivos temporales que accidentalmente han entrado en el arnés de prueba [enlace] (http://stackoverflow.com/questions/1274057/making-git-forget-about-a-file-que -was-track-but-is-now-gitignored/1274447 # 1274447) –