La semana pasada se presento el lanzamiento de la nueva versiĆ³n del sistema de control de fuente distribuida Git 2.23. En comparaciĆ³n con la versiĆ³n anterior, se realizaron poco mĆ”s de 500 cambios en esta nueva versiĆ³n.
Pero entre las mejoras recientemente introducidas en esta nueva versiĆ³n, las que reciben la mayor atenciĆ³n son git switch y git restore, estos son dos comandos experimentales especĆficos que pueden usarse para reemplazar en cierta medida el comando git checkout. Para quienes desconocen de git, deben saber que este es uno de los sistemas de control de versiones mĆ”s populares, confiables y de alto rendimiento que proporciona herramientas flexibles de desarrollo no lineal basadas en la ramificaciĆ³n y fusiĆ³n de versiones.
Para garantizar la integridad de la historia y la resistencia a los cambios en retrospectiva, se utiliza un hash implĆcito de toda la historia previa en cada confirmaciĆ³n, y tambiĆ©n es posible firmar digitalmente a los desarrolladores de etiquetas y confirmaciones individuales.
Principales novedades de git 2.23
En esta nueva versiĆ³n de git se presentan los comandos experimentales antes mencionados āgit switch y git restoreā.
Estos nuevos comandos estĆ”n diseƱados para separar las funciones Ā«git checkoutĀ» sueltas, como la manipulaciĆ³n de ramas (cambio y creaciĆ³n) y la restauraciĆ³n de archivos en el directorio de trabajo (Ā«git checkout $ commit - $ filenameĀ» ) o inmediatamente en el Ć”rea de preparaciĆ³n (Ā«--stagingĀ«, no tiene ningĆŗn anĆ”logo en el Ā«git checkoutĀ«).
git checkout es un comando que permite, por ejemplo, cambiar ramas o crear nuevas ramas en un repositorio.
Si un usuario desea editar archivos individuales o incluso restablecer los nombres de archivo en el repositorio en su disco duro para que sean similares a sus archivos, tambiƩn puede usar git checkout. AdemƔs de estas posibilidades, se pueden realizar otras acciones con el comando git checkout .
Vale la pena seƱalar que, a diferencia de Ā«git checkoutĀ«, Ā«git restoreĀ» elimina los archivos no rastreados de los directorios restaurados (Ā«–no-overlayĀ» por defecto).
Con git restore, es mucho mĆ”s fĆ”cil determinar exactamente quĆ© archivos cambiarĆ”n, cĆ³mo cambiarĆ”n y dĆ³nde cambiarĆ”n. De hecho, en lugar de usar el complicado comando git checkout, git restore proporciona 2 opciones para especificar dĆ³nde irĆ”n los cambios restaurados.
Por lo tanto, si pasa el parĆ”metro --worktree (o no especifica nada), los cambios se realizarĆ”n en el repositorio de su disco duro. Sin embargo, si pasa el parĆ”metro --staged, los cambios irĆ”n al Ćndice. Finalmente, si pasa ambos parĆ”metros, los cambios irĆ”n a las dos ubicaciones respectivas.
En git 2.23 se agregĆ³ la opciĆ³n Ā«git merge --quitĀ«, que, como Ā«–abortĀ», detiene el proceso de fusiĆ³n de ramas, pero deja intacto el directorio de trabajo. Esta opciĆ³n puede ser Ćŗtil si es preferible emitir algunos de los cambios realizados durante la fusiĆ³n manual como una confirmaciĆ³n por separado.
Los comandos git clone, git fetch y git push ahora tienen en cuenta la presencia de commits en repositorios vinculados ( alternativos ).
Se agregaron las opciones Ā«git blame --ignore-revĀ» y Ā«--ignore-revs-fileĀ» para omitir las confirmaciones que hicieron modificaciones menores (por ejemplo, arreglos de formato);
Por otro lado podremos encontrar la adiciĆ³n de la opciĆ³n Ā«git cherry-pick --skipĀ» para omitir el compromiso de conflicto (anĆ”logo memorizado de la secuencia Ā«git reset y git cherry-pick --continueĀ«)
A partir de esta versiĆ³n, git log tendrĆ” en cuenta de manera predeterminada los cambios realizados por mailmap, similar a lo que ya estĆ” sucediendo en git shortlog.
La operaciĆ³n de actualizaciĆ³n del grĆ”fico commit (core.commitGraph) presentado en 2.18 se acelerĆ³ significativamente. TambiĆ©n acelerĆ³ git para cada referencia en caso de usar varias plantillas y redujo el nĆŗmero de llamadas de auto-gc en Ā«git fetch --multipleĀ«.
Se ha agregado la configuraciĆ³n status.aheadBehind, fijando la opciĆ³n Ā«git status - [no-] ahead-behindĀ» de forma continua.
Ā«git branch --listĀ» ahora siempre muestra HEAD separado al comienzo de la lista, independientemente de la configuraciĆ³n regional.
MĆ”s allĆ” de estas mejoras, esta nueva versiĆ³n de Git ahora puede usar las referencias de otra soluciĆ³n como parte de la verificaciĆ³n del objeto conectado que puede ocurrir cuando clona un repositorio y especifica otro durante la clonaciĆ³n o en otro.
Si quieres conocer mas al respecto puedes consultar el siguiente enlace.