Las instalaciones de Composer vcs (git repo) no se comprometerán con el repository principal

Cuando instalo una dependencia de BitBucket (git repo) a través de vcs en la configuration del repository, clona el repository. Luego, cuando confirmo mi proyecto principal, no confirma los files, solo una reference de enlace al repository de dependencia.

Cómo puedo

a) comprometer estos files en el repository padre de git. Para que aparezcan en la interfaz BitBuckets (y otros clones o files zip descargados)

b) decirle al compositor que descargue el file comprimido para la dependencia en lugar de clonar el repository. He especificado "prefernetworking-install": "dist" en el composer.json pero no hizo nada. Nota: este es un repository privado.

Primero, no debe editar y / o comprometerse desde los repositorys que se crean en el directory /vendor (o la location que definió para actuar como este directory).

El caso habitual es que incluya una biblioteca de otra persona, y no se espera que tenga derechos de compromiso para el repository externo. Si desea realizar un cambio o implementar una característica, puede haber un flujo de trabajo como requestes de extracción, rastreador de problemas, etc. Para get su actualización, espere a que aparezca una nueva versión y luego llame a la composer update .

Las mismas reglas se aplican a sus propias bibliotecas. Debería haber notado que cuando no excluye el directory /vendor través de .gitignore en su proyecto principal, cualquier repository remoto clonado por Composer se trata como un submodule de git. Supongo (sin experiencia con ellos) que las reglas habituales para tener submodules se aplicarían en ese momento.

Pero recomendaría no desarrollar de esa manera. Realmente debería tener dos repositorys distintos, cada uno capaz de trabajar por sí mismo: su biblioteca debe desarrollarse por separado del proyecto principal, y cualquier desarrollo allí puede ser enviado a BitBucket. Luego puede actualizar el directory del proveedor con Composer.

Ahora la descarga ZIP: Composer tiene un event handling caso especial si el repository está alojado en Github. Github proporciona una interfaz para download bolas ZIP del repository, con tags, twigs o identificadores de compromiso como la key. Estas descargas son legibles por todo el mundo, por lo que no hay problemas de authentication.

Su propia biblioteca también puede proporcionar una location de descarga para un file ZIP de esa versión. Pero es bastante complicado asegurarse de que siempre se mantenga correctamente si lo hace manualmente. Le sugiero que use un software para esto: Satis ( descripción detallada ).

Satis crea al less dos files estáticos que necesita alojar en un server web accesible desde sus máquinas de desarrollo, y opcionalmente también puede crear files ZIP para cada label que encuentre en sus repositorys.

A continuación, cambiaría las references manuales de sus repositorys en el proyecto principal a un solo puntero al server web de hospedaje de Satis.

Y cada vez que crea una nueva label en uno de sus repositorys, ejecuta nuevamente Satis para search la nueva información y crear nuevos files ZIP.

Solo si proporciona una location de descarga ZIP, experimentará una diferencia con la opción de prefernetworking-install=dist . Sin una location de descarga, Composer siempre clonará el repository original.