Desarrollo

Creo que no es la primera vez que te cuento que, habitualmente, en las empresas del sector los equipos se plataforman con sistemas operativos Windows. En Windows las líneas de código finalizan con un retorno de carro y un salto de línea, CRLF, pero en Linux y Mac, dichos finales se representan únicamente con saltos de línea, LF. En la gestión de un proyecto donde los programadores usan distintos sistemas operativos, o simplemente deseas mantener un tipo de fin de línea distinto al del sistema operativo que estas usando en el desarrollo, puede ser muy frustrante gestionar los cambios entre versiones de código. Esto se debe a que Git interpretará cambios en cada línea del código, pues donde había simplemente LF, tu editor colocó CRLF, y no podrás discernir los cambios reales. Git, sin embargo, dispone de una configuración para gestionar estos casos relativos a los finales de línea, core.autocrlf.

En ocasiones te puede tocar trabajar en un proyecto cuyo repositorio cuenta ya con varios años de historia. Clonar este tipo de proyectos puede terminar en un error debido a la cantidad de datos a ser transferidos y, por tanto, es preferible hacer un clonado superficial. Un clonado superficial de un repositorio Git consiste en clonar únicamente parte de la historia del repositorio, y lo puedes hacer con una instrucción similar a la que sigue:

En muchas empresas es habitual plataformar únicamente el sistema operativo Windows en los equipos facilitados a los empleados, de modo que, si quieres disponer de las bondades de Linux para desarrollar tu trabajo, la opción más factible es usar el susbsitema Linux que Windows incluye, WSL. Desde su segunda versión WSL se ejecuta en una máquina virtual que intenta ser lo más liviana posible, pero que usa un archivo vhdx que crece con el uso de dicho subsistema y, aunque liberes espacio en el subsistema Linux, la realidad es que no vas a recuperar espacio de tu disco duro si no manipulas directamente el archivo vhdx. Lo primero que necesitas es saber dónde se encuentra dicho archivo. En el caso de que estés usando una distribución Ubuntu, la dirección será similar a esto:

Hay varios motivos por los cuales podrías querer traer la información de un repositorio de código, versionado con Subversion, a tu repositorio de código versionado con Git, desde sincronizar ambos repositorios durante un periodo de transición de gestor de versiones hasta, simplemente, aprovechar las características de git para la gestión de ramas antes de subir nuevo código al repositorio de Subversion. Estos motivos son los que justifican la existencia de git-svn, una característica de Git que nos proporciona comandos para gestionar un flujo bidireccional entre Git y Subversion.