usar tag remote how hacer drop delete create como git unity3d git-submodules

remote - how to delete tag git



Submódulos unity3d y git ¿es posible? (4)

¿Tal vez quieras usar enlaces simbólicos / enlaces duros?

<Master Project Folder> <----- no .git here | |-<Unity Main Project Folder> | |- .git | |- Assets | |-Company Name | |- MainProjectA | |- LibraryA ------ symlink to --+ | |- .gitignore <--------+ | | |- Library | | | |- ProjectSettings add LibraryA | | |- .gitignore | | | |-<Unity LibraryA Folder> | | |- .git | | |- Assets | | |-Company Name | | |- LibraryA <-------------------------+ | |- Library | |- ProjectSettings | |- .gitignore

Esto debería funcionar, a pesar de que Unity se queja de los enlaces simbólicos. Al menos en OSX.

Otra forma (e IMO más correcta) es tener LibraryA como un submódulo y tener un proyecto de prueba separado para él (actualmente su Unity LibraryA Folder ).

He realizado más de 2 años en esta configuración (2-3 repositorios vinculados) y git ha funcionado bien. Tal vez su cliente gráfico no es tan bueno? Prueba el cliente de escritorio de gitx-dev o github (que también funciona para repositorios que no son de github), o simplemente aprende la línea de comandos, funciona.

Ah, y los problemas con la adición de un submódulo a un directorio existente: elimine primero el directorio y confirme.

TLDR; Esta va a ser una publicación larga pero estoy seguro de que muchos de ustedes, desarrolladores de unity3d, también están teniendo el mismo problema que yo. Un problema que necesita una respuesta definitiva clara, de una vez por todas, para salvar nuestra cordura colectiva.

Así que he estado usando git durante los últimos 2 años, pero no me he zambullido demasiado en él. Puedo ramificar / fusionar push pull de bitbucket / github, etc. y eso funciona bien para aplicaciones regulares de win / tradicionales.

Aquí está el problema Hace mucho tiempo que pasé de xna / silverlight a unity3d y en unidad para agregar una referencia a una biblioteca, en realidad tienes que copiar los archivos fuente de esa biblioteca en tu carpeta de proyecto de unidad. Aunque la unidad le permite colocar archivos * .dll en una carpeta de complementos, existen problemas obvios de compatibilidad entre plataformas, y por lo tanto, nunca quiero ir allí.

Tengo más de una docena de proyectos de biblioteca que proporcionan varias funcionalidades desde AI, gestión de contenido, registro, sistema de entrada de usuario abstraído, etc. y he estado trabajando en un nuevo editor de niveles para un juego futuro que haré.

Cada proyecto individual de biblioteca es un proyecto de unidad y los archivos de código para cada proyecto están organizados en unidad como tal

Assets/<company name>/<project name>/ Assets/<company name>/<library name>/ Assets/<company name>/<another library name>/

Hago esto para mantener las cosas altamente organizadas a diferencia de muchos de los otros activos que están en la tienda de activos de la unidad. :(

Así que mi proyecto de editor de nivel está usando múltiples proyectos de biblioteca cuyo código ha sido importado mediante copiar y pegar. Cada una de esas bibliotecas están alojadas en sus propios repositorios git locales. Entonces, cuando copio, pego los archivos de código de los proyectos de la biblioteca a mi proyecto principal de unidad, automáticamente pierdo la posibilidad de enviar los cambios que realizo al repositorio git de esas bibliotecas.

Lo que he estado haciendo este año pasado ha sido el barbecho

  1. Comience un proyecto principal Assets/<company name>/<main project name>/
  2. Importar cualquier proyecto de biblioteca (copiar / pegar archivos de código) Assets/<company name>/<library name>/
  3. Si necesito hacer un cambio en una de las bibliotecas, generalmente solo edito los archivos de código de las bibliotecas que están en el proyecto principal en el que estoy trabajando. (de lo contrario, se produce más complejidad)
  4. Como el proyecto principal también es un repositorio de git, los cambios que realizo en los archivos de la biblioteca también se comprometen con el repositorio del proyecto principal.
  5. Después de un tiempo utilizo CodeCompare (una utilidad diff) para hacer una comparación de carpetas de Assets/<company name>/<library name>/ con la ubicación original de la biblioteca donde copié previamente los archivos de la biblioteca.
  6. Comparo minuciosamente cada archivo de código modificado diff por diff y migro los cambios realizados en mi proyecto principal a la ubicación original de la biblioteca.
  7. Ahora que ya está hecho, la biblioteca es un repositorio git, así que de nuevo (segunda vez) tengo que hacer commits sobre los diversos cambios que se realizaron en los archivos de código.

Junto con esa locura, aquí yace otro problema. El proyecto principal no es el único proyecto principal que tengo en marcha en este momento. Tengo un puñado de proyectos que hacen referencia (a través de copiar / pegar) estas otras bibliotecas. Así que ahora que actualicé el código para la biblioteca y lo comprometí, ahora tengo que volver a revisar cada proyecto principal que usa la biblioteca y copiar / pegar los cambios del repositorio de git de las bibliotecas a esos proyectos principales.

Flujo de trabajo summerized

MainProjectA-> Archivos de código copiados de LibraryA-> Archivos LibraryA modificados dentro de MainProjectA-> Archivos LibraryA combinados mediante comparación de diferencias a la ubicación original de la carpeta LibraryA-> Archivos de código de LibraryA luego copiados a otros proyectos que utilizan LibraryA IE: MainProjectB, MainProjectC, MainProjectD .

¡Buen señor! A medida que mis diversos proyectos se hacen cada vez más grandes, este problema se agrava más y más. Este sistema funciona pero es muy muy tedioso.

Descanso

Así que un poco despotricar. / TakesDeepBreath / suspiro Me niego a usar la línea de comando git. Se trata de MS-DOS ala 1980. Son 20 malditas 14 personas. 2014 y nosotros, los desarrolladores, seguimos haciendo gestos con líneas de comando. En este día y edad, espero más. No estoy aprendiendo básicamente un nuevo lenguaje de línea de comandos y mucho menos tengo que volver atrás y cuarto entre ventanas y aplicaciones solo para hacer algo tan fundamentalmente simple como confirmar un cambio de código. Algo que se puede lograr con 2-3 rápidos clics del mouse y un breve mensaje mecanografiado es todo lo que se necesita. git = new hawtness + complejidad de línea de comando innecesaria

Una vez dicho esto, utilizo las características de git vs2013 incorporadas para realizar commits y branching / merging, etc. Pero parece que no es compatible con los submódulos, por lo que puedo decir. Entonces para eso uso SourceTree.

Fin del intermedio.

Ingresa git submodule hell

Como dije, aún no he usado git mucho más allá de su funcionalidad básica básica y solo he realizado pruebas preliminares a través de proyectos de prueba, pero no puedo hacer que git funcione de manera confiable de la manera en que lo necesito y, a menudo, cuando trabajo con submódulos hay un poco de confusión, y muchas veces no se comprometerá debido a varios errores.

Lo que quiero hacer es esto

  1. Cree un nuevo proyecto de unidad llamado MainProjectA y conviértalo en un repositorio local
  2. Agregue submódulo (s) de git a MainProjectA desde LibraryA (repositorio local), LibraryB (repositorio local), etc.
  3. Si realizo cambios a los archivos de código relacionados con LibraryA dentro de MainProjectA, deseo la capacidad de volver a asignar estos cambios específicos al repositorio de LibraryA dentro de MainProjectA.

Incluso he llegado a comenzar a escribir una utilidad que sincronizaría automáticamente archivos entre 2 carpetas diferentes tan pronto como detecte un cambio. Pero lo abandoné porque, aunque resolvería los problemas de sincronización, no resolvería los problemas de commit de git.

Otro problema es que todos mis proyectos de unidades existentes que tienen un repositorio local se configuran como barbechos

<Unity Main Project Folder> |- .git |- Assets |-Company Name |- MainProjectA |- Library |- ProjectSettings |- .gitignore <Unity LibraryA Folder> |- .git |- Assets |-Company Name |- LibraryA |- Library |- ProjectSettings |- .gitignore

Lo que quiero hacer es tener una carpeta LibraryA en mi proyecto principal que sea un submódulo de mi proyecto LibraryA, más específicamente, quiero que solo se incluya como submódulo el contenido de <Unity LibraryA Folder>/Assets/Company Name/LibraryA/ en la carpeta principal de mi proyecto <Unity Main Project Folder>/Assets/Company Name/LibraryA/ Carpeta del proyecto principal de <Unity Main Project Folder>/Assets/Company Name/LibraryA/

<Unity Main Project Folder> |- .git |- Assets |-Company Name |- MainProjectA |- LibraryA (submodule) |- Library |- ProjectSettings |- .gitignore

Pero SourceTree / git se queja de que no puedo agregar un submódulo a una carpeta repo existente. <Unity Main Project Folder>/Assets/Company Name/

Iba a continuar escribiendo, pero ... sí, creo que ya es suficiente, y mi objetivo debería describirse bastante bien ahora.

Conclusión

Supongo que también podría preguntar si weather git ha madurado lo suficiente como un producto que incluso me permitirá hacer lo que estoy tratando de hacer. ¿O simplemente no es posible dada la arquitectura de git para apoyar lo que estoy tratando de hacer?

Cada búsqueda ha quedado vacía, YouTube no es una ayuda y una pérdida de tiempo, sin mencionar que cada ejemplo que puedo encontrar es un ejemplo de línea de comando, y no toca submódulos.

En una aplicación de Windows normal, los submódulos no serían un problema. El problema está específicamente en cómo a la unidad le gusta tener todos los archivos de código en su proyecto. Eso y cómo trato de mantener intacta mi estructura de carpetas organizadas.

Por favor ayuda. Por favor. Purdy por favor. ¡TE LO RUEGO! ¡TE LO RUEGO! EN MI FRIEAKIN KNEES BEGGING! :PAG


He estado en la misma situación con Unity. Honestamente, lo que quieres hacer es evitar Git para esto y usar SVN con Externs. Los Submódulos de Git realmente no son lo que estás buscando por experiencia personal, no hay forma de hacer que se comporten exactamente como deseas para Unity. Git tiene muchas ventajas sobre SVN, pero los SubModules definitivamente aún no son uno de ellos.

Sin embargo, SVN Externs funciona exactamente de la manera que desee. Puede consultar la carpeta específica en el repositorio de LibraryA directamente en su repositorio principal. A partir de ahí, casi todos los clientes SVN que he usado (estoy en OS X y uso Cornerstone para esto) te permiten actualizar directamente y comprometerse con esa carpeta externa, que modificará el repositorio de LibraryA real. Además, cuando realice una actualización en la base del repositorio principal, también se actualizarán todos sus externos. Si necesita ramificar su proyecto, puede señalar externos a revisiones específicas en lugar de a la cabeza.


esto es lo que hice.

Primero: si ya ha copiado los archivos de LibraryA en su proyecto y su proyecto está usando los objetos y scripts de LibraryA, debe tener mucho cuidado. Asegúrese de no tener absolutamente nada modificado desde su repositorio de Git cuando comience ...

Ahora, con Unity cerrado, elimine la carpeta LibraryA que incluye su proyecto. La unidad, si estaba abierta, comenzaría a ahogarse y morir en este punto.

Ahora, cree un directorio de enlace permanente (destino de la carpeta mklink / J) en su proyecto, en la carpeta de Contenidos, que alineará e imitará la carpeta que acaba de eliminar. El nuevo enlace fijo debe verse casi exactamente como lo que acaba de eliminar.

Abre tu proyecto en Unity. Si tiene suerte, cuando haya terminado de importar activos, todavía tendrá los objetos correctos en los lugares correctos, pero habrá actualizado un montón de cosas en su carpeta Biblioteca. Está bien.

Asegúrese en Git de que el repositorio que representa a LibraryA no tiene archivos modificados en él. La simple importación de ese directorio w / hardlink a LibraryA NO debería haber tocado los archivos de LibraryA. Si lo hizo, probablemente haya hecho algo mal.

Verifique todos los cambios nuevos en la carpeta Biblioteca de su proyecto.

Ahora eres libre de continuar desarrollando en Unity.

Er, con suerte.