¿Para qué usaría git-worktree?

Leí la publicación de Github en git-worktree . Escriben:

Suponga que está trabajando en un repositorio Git en una rama llamada feature, cuando un usuario informa un error de alta urgencia master. Primero, crea un árbol de trabajo vinculado con una nueva rama, hotfixdesprotegido en relación con el maestro […] Puede corregir el error, aplicar una revisión y crear una solicitud de extracción.

Cuando estoy trabajando en una rama llamada característica y se informa de algún error de alta urgencia en el maestro, generalmente guardo todo lo que estoy trabajando y creo una nueva rama. Cuando termine, puedo seguir trabajando. Este es un modelo muy simple, he estado trabajando así durante años.

Por otro lado, usar git-worktree tiene sus propias limitaciones:

Por ejemplo, no está permitido tener la misma rama desprotegida en dos árboles de trabajo vinculados al mismo tiempo, porque eso permitiría que los cambios comprometidos en un árbol de trabajo desactiven la otra.

¿Por qué elegiría un flujo de trabajo más complicado para un problema que ya se ha resuelto?

¿Hay algo sobre git-worktreeeso que no se pueda hacer de antemano y que justifique esta característica completamente nueva y compleja?

Para mí, git worktree es la mayor mejora desde hace mucho tiempo. Estoy trabajando en el desarrollo de software empresarial. Allí, es muy común que tenga que mantener versiones antiguas como la que lanzó hace 3 años. Por supuesto, tiene una rama para cada versión para que pueda cambiar fácilmente a ella y corregir un error. Sin embargo, el cambio es costoso, porque mientras tanto reestructuró completamente el repositorio y quizás construyó el sistema. Si cambia, su IDE se volverá loco tratando de adaptar la configuración del proyecto.

Con worktree, puede evitar esa constante reconfiguración. Verifique esas ramas viejas en carpetas separadas usando worktree. Para cada sucursal, tienes un proyecto IDE independiente.

Por supuesto, esto podría haberse hecho en el pasado clonando el repositorio varias veces y este ha sido mi enfoque hasta ahora. Sin embargo, eso también significó malgastar el espacio en el disco duro y peor aún necesitar recuperar los mismos cambios del repositorio varias veces.

Puedo ver algunos usos para esto.

Si tiene un conjunto de pruebas que se ejecuta durante mucho tiempo, imagine horas y lo inicia, efectivamente bloquea esa copia de trabajo hasta que se completen las pruebas. Cambiar ramas durante esas pruebas las rompería de una manera que sería difícil de entender.

Entonces git-worktree, podría tener una segunda idea lanzada para otra sucursal que trabaje allí.

Además, cuando cambio a otra rama para hacer una investigación rápida, mi IDE piensa que muchos archivos cambiaron repentinamente e indexarán todos esos cambios, solo para tener que volver a indexarlos nuevamente cuando vuelva a cambiar.

Un tercer caso de uso sería hacer una comparación de archivos usando otras herramientas que git-diff, como es normal diff, entre dos directorios en lugar de dos ramas.

Un uso obvio es comparar simultáneamente el comportamiento (no fuente) de diferentes versiones, por ejemplo, diferentes versiones de un sitio web o simplemente una página web.

Probé esto localmente.

• crear un directorio page1.

• dentro crea el directorio srcy git initlo.

• en srccrear page1.htmlcon un poco de contenido y comprometerlo.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• en srcmaster agregue más texto page1.htmly confírmelo.

• $ git branch sty1

• edite page1.htmlen la sty1rama (agregue un estilo CSS distintivo) y agregue commit.

• $ git worktree add ../S1 sty1

Ahora puede usar un navegador web para abrir y ver estas 3 versiones simultáneamente:

• ..\page1\src\page1.html // lo que sea que git tenga como actual

• ..\page1\V0\page1.html // la versión inicial

• ..\page1\S1\page1.html // la versión de estilo experimental

1. Hay razones legítimas por las que puede querer / necesitar múltiples worktrees en el sistema de archivos a la vez.

   • manipular los archivos desprotegidos mientras necesita realizar cambios en otro lugar (por ejemplo, compilar / probar)

   • diferenciar los archivos a través de herramientas diff normales

   • Durante los conflictos de fusión, a menudo quiero navegar a través del código fuente ya que está en el lado fuente mientras resuelvo conflictos en los archivos.

   • Si necesita cambiar mucho de un lado a otro, hay que perder el tiempo al pagar y volver a verificar que no tiene que ver con varios árboles de trabajo.

   • El costo mental del cambio de contexto mental entre ramas a través de git stashing no es realmente medible. Algunas personas encuentran que existe un costo mental para el almacenamiento que no existe simplemente abriendo archivos desde un directorio diferente.

2. Algunas personas preguntan "por qué no hacer múltiples clones locales". Es cierto que con el indicador "--local" no tiene que preocuparse por el uso de espacio extra en el disco. Esto (o ideas similares) es lo que he hecho hasta este momento. Las ventajas funcionales de los árboles de trabajo vinculados sobre los clones locales son:

   1. Con los clones locales, sus árboles de trabajo adicionales (que están en los clones locales) simplemente no tienen acceso a las ramas de origen o ascendentes. El 'origen' en el clon no será el mismo que el 'origen' en el primer clon.

      • Correr git log @{u}..o git diff origin/feature/other-featurepuede ser muy útil y esto ya no es posible o más difícil. Estas ideas son técnicamente posibles con clones locales a través de una variedad de soluciones, pero cada solución que pueda hacer se hace mejor y / o más simple a través de vías de trabajo vinculadas.

   2. Puede compartir referencias entre árboles de trabajo. Si desea comparar o tomar prestados cambios de otra sucursal local, ahora puede hacerlo.

tl; dr: cada vez que desee que se revisen dos árboles de trabajo al mismo tiempo por cualquier razón, git-worktreees una forma rápida y eficiente de hacerlo.

Si crea otro árbol de trabajo, la mayoría de las partes del repositorio (es decir .git) se compartirán, lo que significa que si crea una rama o obtiene datos mientras está en un árbol de trabajo, también será accesible desde cualquier otro árbol de trabajo que tenga. Supongamos que desea ejecutar su conjunto de pruebas en una sucursal sin tener que empujarlo a algún lugar para clonarlo, y desea evitar la molestia de clonar su repositorio localmente, usar git-worktreees una buena manera de crear solo un nuevo pago de algún estado en un lugar separado, ya sea temporal o permanentemente. Al igual que con un clon, todo lo que necesita hacer cuando haya terminado es eliminarlo, y la referencia a él será recolectada de basura después de un tiempo.

Originalmente me topé con esta pregunta después de preguntarme para qué podrían usarse estos elegantes árboles de trabajo. Desde entonces los he integrado en mi flujo de trabajo y, a pesar de mi escepticismo inicial, he llegado a encontrarlos bastante útiles.

Trabajo en una base de código bastante grande, que lleva bastante tiempo compilar. Por lo general, tengo la rama de desarrollo actual en mi máquina junto con la rama de características en la que estoy trabajando actualmente más la rama maestra, que representa el estado actual del sistema en vivo.

Obviamente, uno de los mayores beneficios para mí es que no tengo que volver a compilar todo cada vez que cambio de sucursales (es decir, árboles de trabajo). Un buen efecto secundario es que puedo ir al árbol de trabajo de desarrollo, hacer cosas allí, cambiar el directorio al árbol de trabajo de mi rama de características actual y luego volver a crearlo sin tener que tirar primero.

Tengo uno bastante inusual: estoy desarrollando Windows y Linux en la misma máquina . Tengo un VirtualBox ejecutando Linux dentro de mi caja de Windows. VirtualBox monta algunos directorios de Windows y los usa directamente dentro de la máquina Linux. Esto me permite usar Windows para administrar archivos pero construir dentro de Linux. Este es un proyecto multiplataforma, por lo que se basa en Windows y Linux desde la misma estructura de directorios.

El problema es que los sistemas de compilación de Linux y Windows chocan entre sí cuando se usan en el mismo directorio; Hay algunos pasos de compilación complicados para descargar bibliotecas, etc., que usan los mismos nombres de directorio. La versión de Windows del sistema de compilación descarga las bibliotecas específicas de Windows, y la versión de Linux del sistema de compilación descarga las bibliotecas específicas de Linux.

En un mundo ideal, el sistema de compilación se modificaría para que Windows y Linux puedan coexistir dentro del directorio, pero por ahora, el problema se está abordando con worktrees. La carpeta "Linux" puede generar artefactos de compilación específicos de Linux, y la carpeta "Windows" puede generar artefactos de compilación específicos de Windows. Si bien esta no es una solución ideal, hace una buena pausa mientras espera que se solucionen los errores del sistema de compilación.

Es cierto que worktree no fue diseñado para esto; Tengo que mantener la versión de Windows y la versión de Linux en ramas separadas, aunque realmente prefiero que estén en la misma rama. Aún así, está haciendo el trabajo, y es un caso poco convencional de worktree que salva el día.

En un nuevo proyecto para mí, he creado una función. Pero algunas especificaciones fallaron. Para comparar resultados con master, creé un work-treerepositorio. Comparé los resultados paso a paso en el código de ejecución, hasta entender qué salió mal.

Estoy usando git worktreepara el desarrollo de aprendizaje automático.

Tengo un código funcional principal y luego quiero dividir ramas de diferentes experimentos (diferentes algoritmos e hiperparámetros diferentes). git worktreeme permite integrar dvc junto con diferentes versiones de mi código especializadas para diferentes algoritmos. Después de ejecutar todos los trabajos de capacitación, evalúo las métricas finales y las combino para dominar la mejor rama / modelo.