Exponer repositorio de Git parcialmente

Meleagant #1 Feb '21 :psyduck:

Tengo un repositorio con un proyecto relativamente grande. El cliente quiere ampliar parte del proyecto subcontratando a una empresa que se encargaría de añadir una funcionalidad muy concreta y específica, pero no quiere compartir con ellos todo el código fuente, sino sólo las partes que necesiten para esa funcionalidad.

Hasta ahora la única forma en que veo esto factible es crear un repositorio separado, copiar manualmente en ese repositorio las partes que quiero hacer visibles, dejar que se desarrolle la funcionalidad en ese repositorio y luego volver a integrar los cambios en el repositorio completo.

¿Alguno os habéis visto en una situación similar o tenéis alguna idea mejor?

desu #2 Feb '21

Deberias concretar mas tu problema. Las dependencias entre los modulos, cuales quieres exponer y cuales deben ser privados. De verdad puedes separarlo todo? Imagino que podeis mockear parte del codigo con interficies o darles algun compilado para que trabajen. O es 100% aislado y facil?

Para lo que comentas puedes mirarlo con submodulos que no se si es a lo que te refieres con "mover y integrar el repositorio".

Master en estado 0
Branch de master con estado 0.
Mueves el codigo en otro git y lo dejas dentro de esta rama como submodulo.
Compartes con el cliente solo el submodulo.
Cada vez que hagas commit en tu branch te hara hacer pull del submodulo tambien para integrar cambios.
Mantienes master en estado 0, pero tu branch de trabajo y el submodulo iran mutando.
Al final podras integrarlo de vuelta.

Otra alternativa es con subtrees. Al no tener nada compartido en teoria tambien son una opcion. Yo prefiero hacer submodulos porque me interesa tener los cambios compartidos, si estais compartiendo compilados por ejemplo seria lo suyo tambien.

1 respuesta

Meleagant #3 Feb '21 :psyduck:

#2 El proyecto es un juego. Básicamente, quieren subcontratar parte del metagame sin exponer el código del propio juego. Están en módulos completamente separados, así que no es problema separarlo, son apenas unas pocas funcionalidades las que habría que modificar (por ejemplo, el primer inicio de sesión te lleva al juego en lugar de al menú, eso habría que cambiarlo para que no se rompa).

Por integrar me refiero a hacer un merge, aunque no tengo claro que pueda hacer un merge del repositorio separado fácilmente. No he hecho merges de repositorios separados nunca, pero me parece que tendría que hacerlo manualmente para evitar que durante el merge se borren archivos que dejaron de existir en el repositorio parcial.

1 respuesta

Kartalon #4 Feb '21 Veterano

Por hacerlo más fácil de mantener yo haría una repo separada y una pipeline de integración automática que integrara el máster en vuestro proyecto principal de la forma más conveniente.

1 respuesta

B

[Borrado] #5 Feb '21

¿Y hacerles firmar un contrato de confidencialidad no entra dentro de los planes? Lo mismo que te puede robar el código un "ajeno", te lo puede robar un trabajador.

Pero vamos, si son modulos separados... crearte un repo para cada modulo y configurarlo publico o privado... luego a la hora de "levantar" el proyecto hacerse un pull de todos para tenerlo actualizado.

1 respuesta

desu #6 Feb '21

#3 Si mira submodulos, sin problemas si esta separado. A mano solo tendras que separar el codigo el primer dia y deshacer el submodulo el ultimo dia.

Imposible perder nada.

1 respuesta

B

[Borrado] #7 Feb '21

#6 ¿Para que submodulos? ¿para tener que hacer un pull de un solo repo? Yo tiraría usando algo como "git-aggregator" y tira millas.

1 respuesta

Meleagant #8 Feb '21 :psyduck:

#4 Le doy una vuelta a esa. El problema es que tengo un montón de trabajo con otras funcionalidades y no tengo mucho tiempo de ponerme a preparar nada muy elaborado. El desarrollo debería ser de unas 6 semanas, así que la pipeline de integración no sería ser algo que se utilice a largo plazo.

#5 Son módulos separados pero no sé aún el alcance que tendrá. Por ejemplo, es posible que tengan que hacer cambios que me obliguen a adaptar el código del inventario del jugador, que se usa tanto en el juego como en el menú.

Lo de el acuerdo y demás, cosas del cliente... yo ahí no me meto. Si no quiere compartir el código es cosa suya xD

1 respuesta

Kartalon #9 Feb '21 Veterano

#8 Hombre, no sé el scope del proyecto y tal, pero si andas muy pillado pues casi que hacer la "integración" a mano y pullear del master y copiar y pegar en la otra repo y pushear con algún tag reconocible por si las moscas. Pero vamos, que siempre que he visto movidas con varias organizaciones colaborando en una mono-repo ha habido lágrimas, casi mejor que repos separadas e integrar como sea.

1 respuesta

desu #10 Feb '21

#7 O submodulos o subtrees.

Se inventaron para este caso de uso. beneficios? todos los de git, desventajas? no deberia haber ninguna.

Usar herramientas externas o re inventarlo tu a mano me parece bobada.

Es mas facil razonar y descartar porque no usar submodulo o subtree que ponerte a sacar alternativas a estos 2.

1 respuesta

B

[Borrado] #11 Feb '21

#9 Es que no solo es venga... a subir código a quien quien quiera! se debería de designar unos roles para mantener el repo. Lo de que se ataque en dos sitios distintos y luego juntar las cosas lo veo más tedioso.
Yo al menos suelo trabajar en repos públicos y cero dramas... algun vez alguno se mosquea porque cree que no recibe toda la atención que se merece o discrepancias en la implementación.... pero es algo lógico que con el otro modo de "cada uno por su lado" se hiba a dar y seguramente con más intensidad.. ya que igual no os comunicáis durante semanas y cuando tal "ohh mierda... ¿que este desastre?".

1 respuesta

B

[Borrado] #12 Feb '21

#10 con git-aggregator puedes juntar lo que te salga del nardo siempre que se respeten las historias. Los submodulos estás atado a como se plantee... el día de mañana quieres meter cambios de otro sitio y ... "oh mierda, los submodulos".

1 respuesta

Kartalon #13 Feb '21 Veterano

#11 Si siendo repos públicas y organizaciones que saben lo que hacen no te digo que no. Pero vamos, por lo que he leído así por encima esto no es una repo pública y la parte a la que se quiere dar acceso es para actualizar meta o lore así que lo mismo es data entry y listo. Que podría haber roles y todo sin problema, pero vamos, viendo que anda pillado y con el scope del proyecto pues... Personalmente veo ambas opciones factibles y que una es más tediosa que otra dependiendo de scope, frecuencia de integración, número de colaboradores y roles de dichos colaboradores.

desu #14 Feb '21

#12 Estos problemas que comentas no aplican en el caso a resolver.

Son problemas de tener submodulos como flujo en un proyecto largo y si te ha dado problemas no eran los submodulos, es que tenias la infra mal montada. si usas submodulos requieres mirar si existen cambios recursivamente cuando haces pulls... en fin, si no sabes usar git no puedes decir que los submodulos dan problemas XD

Puedes decir que para usar submodulos en el dia a dia requieres de tener los hooks configurados... pero los submodulos no dan problemas, los dan el mal uso. de nuevo, esto no aplica al problema.

Yo uso submodulos, 0 problemas. El primer dia configure la infra, asi un pajeet no rompe nada.

Me salgo de la discusion, ha divagado demasiado para mi gusto.

1 respuesta

B

[Borrado] #15 Feb '21

Este es el único repo que conozco que usa submódulos (se que existen mucho otros que lo usan xD)... y lo usan para algo muy muy concreto: https://github.com/ddnet/ddnet (aliviar el peso del repo).

B

[Borrado] #16 Feb '21

#14 Bueno, ya me sales con falacias de "si tu no sabes, callate"... así que, yo ya he terminado por aquí. Adiós. No vengo a medirme la polla con nadie, solo a decir lo que pienso.

1 respuesta

Meleagant #17 Feb '21 :psyduck:

Bueno creo que más o menos me hago una idea de las opciones habituales, muchas gracias por la ayuda a todos

También he encontrado un par de artículos que hablan del tema por si a alguien le sirven:

https://gist.github.com/pglombardo/7630100
https://www.javaer101.com/en/article/16552747.html

desu #18 Feb '21

#16 Si yo hago un push a master sin hacer pull antes tambien puedo romper el git. Lo mismo con submodulos? wow.

Ese era tu razonamiento para decir que los submodulos no eran opcion cuando se inventaron precisamente para estos casos de uso.

Usar mal algo no significa que este algo este mal.

Salu2.

No te lo digo a ti en concreto, ambos habeis propuesto alternativas peores a submodulos y subtrees sin razonar porque estos son malos. Al otro re inventando la rueda ni me he molestado en responderlo porque se que no le hara caso el OP. me parece demasiado obvio.

1 respuesta

Kaledros #19 Feb '21

#18desu:
Si yo hago un push a master sin hacer pull antes tambien puedo romper el git

De hecho no debería ni dejarte hacer eso.

1 1 respuesta

desu #20 Feb '21

#19 porque tienes el historial. En un sub solo apuntas al commit. Por eso requieres de infra. Exacto lo dices bien. Como git puede determinarlo te falla. Con subs no.

A ver si voy a tener que sacar mis notas de cuando enseñaba esto en la uní...

JuAn4k4 #21 Feb '21

Esto se hace por contrato y punto.

Exponer repositorio de Git parcialmente

Usuarios habituales

Tags