remota - Flujo de trabajo de Git: cambio de rama y recompilación lenta
git push example (4)
Trabajo en un gran proyecto de Scala en el que usamos Git para el control de versiones. Mi flujo de trabajo es trabajar en nuevas funciones en mi propia rama y cambiar cuando sea necesario. Varias versiones del código están en sus propias sucursales. Todo muy estándar.
Si tengo que corregir un error en una determinada versión del código, cambiaré a la rama correcta, corregiré el error, cometeré y luego volveré a donde estaba.
El problema es que aunque git es instantáneo al cambiar a otra rama una vez que estoy allí, tengo que volver a compilar el código. Lo que lleva varios minutos. Luego arregle el error, vuelva a mi propia rama y haga otra recompilación, lo que demorará unos minutos más. Parece derrotar el propósito de que Git sea tan rápido.
¿Alguien más ha encontrado esto? ¿Hay maneras de evitarlo? Estoy seguro de que no es un problema específico de Scala (aunque Scala es épicamente lento en la compilación).
actualización 3+ años después
He estado usando la respuesta de @djs (git-new-workdir) durante los últimos años. Ha funcionado muy bien para mí. Tengo un directorio maestro y varios otros directorios (como producción, próximo lanzamiento, etc.) a los que cambio cuando necesito trabajar allí. Hay muy pocos gastos generales y significa que puede cambiar rápidamente a decir, producción, para probar algo, y luego volver a lo que estaba trabajando.
actualización 7+ años después
Parece que git-worktree es el reemplazo de git-new-workdir. Usar:
cd ~/git/my-repo
git worktree add ~/git/my-linked-repo
Puede intentar usar diferentes directorios de destino para diferentes sucursales anulando el outputDirectoryName. Tal vez recoger el nombre de la rama git y configurar el directorio de salida a target- <branch> ; aunque eso significaría que cada nueva rama comienza desde cero.
Puede mejorar drásticamente los tiempos de compilación de scala usando [sbt] [1] o el "compilador de scala rápido". Ambos permiten mantener el compilador en la memoria, lo que mejora enormemente los tiempos de compilación.
Usar un directorio por rama permite evitar tantas recompilaciones. Pero ese flujo de trabajo está mejor soportado por mercurial.
Suponiendo que no desea cambiar el proceso de compilación (basado en hash en lugar de con marca de tiempo), es posible que desee ver la git-new-workdir comandos git-new-workdir en el directorio contrib de la fuente git. Al igual que la sugerencia de clonación, obtendrá varias copias de trabajo, pero en lugar de dos repositorios independientes, obtendrá una con varias copias de trabajo. Entonces, no hay que empujar y tirar entre los repositorios locales.
Es un script de shell y solo se ejecuta en sistemas similares a Unix, pero el concepto se puede replicar en versiones modernas de Windows.
Suponiendo que su sistema de compilación no es demasiado entusiasta acerca de las dependencias (tal vez piense que necesita reconstruirse cuando en realidad no lo hace), la principal forma de solucionar esto es clonar su repositorio:
git clone my-repo my-repo2
Luego, puede trabajar en su clon adicional, y empujar desde él hacia su principal. (Solo debes empujar a las ramas que no están marcadas, pero ese es el punto aquí. También puedes extraer o incluso recuperar y reiniciar o ramificar -f si lo deseas).
Y esto realmente no ocupará mucho espacio, tampoco; Git vincula los objetos dentro del repositorio para los clones locales, por lo que el espacio adicional será la copia extra desprendida.