¿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 enmaster. Primero, crea un árbol de trabajo vinculado con una nueva rama,hotfixdesprotegida en relación con la maestra […] Puede corregir el error, enviar una revisión y crear una solicitud de extracción.
Cuando estoy trabajando en una rama llamada característica y se informa algún error de alta urgencia en master, generalmente guardo todo en lo que estoy trabajando y creo una nueva rama. Cuando termine, puedo seguir trabajando. Este es un modelo muy simple, llevo años trabajando así.
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 cometidos en un árbol de trabajo desincronicen el otro.
¿Por qué elegiría un flujo de trabajo más complicado para un problema que ya se ha resuelto?
¿Hay algo git-worktreeque no se haya podido 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 tengas que mantener versiones antiguas como la que lanzaste hace 3 años. Por supuesto, tienes una rama para cada versión para que puedas cambiar fácilmente a ella y corregir un error. Sin embargo, el cambio es costoso, porque mientras tanto reestructuró completamente el repositorio y tal vez construyó el sistema. Si cambia, su IDE se volverá loco al intentar adaptar la configuración del proyecto.
Con worktree, puedes evitar esa reconfiguración constante. Consulte esas ramas antiguas en carpetas separadas usando worktree. Para cada rama, tienes un proyecto IDE independiente.
Por supuesto, esto se podría haber hecho en el pasado clonando el repositorio varias veces y este ha sido mi enfoque hasta ahora. Sin embargo, eso también significó desperdiciar espacio en el disco duro y, peor aún, tener que 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 completan las pruebas. Cambiar de rama durante esas pruebas las rompería de maneras que serían difíciles de entender.
Entonces git-worktreepodría tener una segunda idea para otra sucursal que trabaje allí.
Además, cuando cambio a otra rama para hacer una investigación rápida, mi IDE cree que muchos archivos cambiaron repentinamente e indexará todos esos cambios, solo para tener que volver a indexarlos nuevamente cuando vuelva a cambiar.
Un tercer caso de uso sería realizar una comparación de archivos utilizando otras herramientas distintas git-diff, como es normal diff, entre dos directorios en lugar de dos ramas.
Un uso obvio es comparar simultáneamente el comportamiento (no el origen) de diferentes versiones, por ejemplo, diferentes versiones de un sitio web o simplemente de una página web.
Probé esto localmente.
crear un directorio
page1.dentro crea el directorio
srcygit initél.en
srccrearpage1.htmlcon un poco de contenido y comprometerlo.$ git branch ver0$ git worktree add ../V0 ver0en
srcmaster agregue más textopage1.htmly confírmelo.$ git branch sty1edite
page1.htmlen lasty1rama (agregue algún estilo CSS distintivo) y agregue confirmarlo.$ git worktree add ../S1 sty1
Ahora puede utilizar 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
Existen razones legítimas por las que es posible que desee o necesite varios árboles de trabajo en el sistema de archivos a la vez.
manipular los archivos extraídos mientras se necesitan realizar cambios en otro lugar (por ejemplo, compilar/probar)
diferenciar los archivos mediante herramientas de diferenciación normales
Durante los conflictos de fusión, a menudo quiero navegar a través del código fuente tal como está en el lado fuente mientras resuelvo conflictos en los archivos.
Si necesita alternar mucho, se pierde tiempo en verificar y volver a verificar que no necesita hacerlo con múltiples árboles de trabajo.
El costo mental del cambio de contexto mental entre ramas a través de git stashing no es realmente mensurable. Algunas personas descubren que el almacenamiento oculto supone un coste mental que no existe simplemente abriendo archivos desde un directorio diferente.
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 adicional 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:
Con los clones locales, sus árboles de trabajo adicionales (que están en los clones locales) simplemente no tienen acceso al origen o a las ramas ascendentes. El "origen" del clon no será el mismo que el "origen" del primer clon.
- Correr
git log @{u}..ogit diff origin/feature/other-featurepuede ser muy útil y ya no es posible o es más difícil. Estas ideas son técnicamente posibles con clones locales a través de una variedad de soluciones, pero todas las soluciones que pueda implementar se hacen mejor y/o más simples a través de árboles de trabajo vinculados.
- Correr
Puede compartir referencias entre árboles de trabajo. Si desea comparar o tomar prestados cambios de otra sucursal local, ahora puede hacerlo.
Mi caso de uso favorito absoluto y probablemente el más común que todos deberían usar git worktreees revisar las solicitudes de extracción de los compañeros de equipo, mientras sigo trabajando en los cambios en el árbol de trabajo principal. 😎
