Lanzamiento del sistema de control de código fuente distribuido Git 2.22

Presentado por lanzamiento del sistema de control de código fuente distribuido Git 2.22.0. Git es uno de los sistemas de control de versiones más populares, confiables y de alto rendimiento, y proporciona herramientas de desarrollo no lineales flexibles basadas en ramificaciones y fusiones. Para garantizar la integridad del historial y la resistencia a cambios retroactivos, se utiliza el hash implícito de todo el historial anterior en cada confirmación, y también es posible certificar etiquetas individuales y confirmaciones con firmas digitales de los desarrolladores.

En comparación con la versión anterior, la nueva versión incluyó 745 cambios, elaborados con la participación de 74 desarrolladores, de los cuales 18 participaron en el desarrollo por primera vez. El principal innovaciones:

  • Disponible desde la versión 1.18, el nuevo modo de rebase de confirmación "git rebase --rebase-merges" reemplaza la antigua opción "--preserve-merges", que ahora está en desuso. La operación "git rebase" se utiliza para reemplazar una serie de confirmaciones con una nueva confirmación base, por ejemplo, para mover una rama separada que está desarrollando alguna característica nueva al estado actual de la rama maestra, que incluye correcciones agregadas después de la rama. :

    o - o - o (mi-característica)

    /

    o - o - o - o - o (maestro)

    o - o - o (mi-característica)

    /

    o - o - o - o - o (maestro)

    Para preservar la estructura de la rama en una rama migrada, anteriormente se podía usar la opción “--preserve-merges”, que, cuando se ejecutaba en modo interactivo (git rebase -i --preserve-merges), permitía editar el historial de confirmaciones, pero no garantizaba la preservación completa de la estructura del repositorio. El nuevo modo “--rebase-merges” le permite preservar la estructura de los cambios en la rama que se está migrando, al mismo tiempo que proporciona una gama completa de operaciones interactivas, que incluyen eliminar, reagrupar y cambiar el nombre de las confirmaciones.

    Por ejemplo, "--rebase-merges" permite Vuelva a cargar las confirmaciones de una rama separada a una rama maestra más nueva, mientras mantiene la estructura de la rama en la rama migrada, y realice algunos cambios en las notas de confirmación sobre la marcha.

  • Se agregó soporte para crear una nueva rama basada en el resultado de determinar la base de fusión de otras dos ramas (base de fusión, vinculación a un ancestro común) usando las construcciones "git branch new A...B" y "git checkout -b new A...B”, en el que “A ...B" implica definir una base de fusión entre dos confirmaciones especificadas, similar a cómo "git checkout A...B" cambia el HEAD a la confirmación base y "diff A. ..B" muestra los cambios entre el compromiso "B" y el mismo que el compromiso "A" "Ancestor.

    Por ejemplo, cuando se trabaja en una rama my-feature separada, esta función se puede usar cuando se desea comenzar desde una rama diferente, por ejemplo, desde el mismo lugar en la rama master desde donde se desprotegió la rama my-feature. Anteriormente, esto requería examinar manualmente el registro de cambios, lo cual era inconveniente si tenía un gran historial de cambios, y luego ejecutar "git merge-base master my-feature" para calcular el hash de la base de combinación entre las ramas master y my-feature. y crear una nueva rama relativa al ancestro común "git Branch my-other-feature hash". En Git 2.22, puedes usar la sintaxis "git branch my-other-feature A...B" para crear una rama relativa a la base de fusión de otras dos ramas;

  • Se agregó la opción "git branch --show-current" para mostrar el nombre de la rama obtenida durante la operación de pago;
  • Se agregó la opción "git checkout —no-overlay — dir", que permite, al realizar una operación de pago, llevar el contenido del directorio dir a un formulario que corresponda completamente al estado de la rama maestra. Por ejemplo, si hay un archivo en la copia local del directorio dir que no está en la rama master, entonces, de forma predeterminada, al ejecutar "git checkout master - dir" se dejará, y si el archivo "--no-overlay" ”Se especifica la opción, se eliminará;
  • El comando "git diff" utiliza una API universal para analizar opciones, lo que permite unificar el manejo de opciones con otras utilidades de git. Por ejemplo, en “git diff”, todas las opciones ahora tienen sus antagonistas (“--function-context” y “--no-function-context”);
  • Se agregó la capacidad de filtrar etiquetas extendidas adjuntas a confirmaciones en la salida del "registro de git" ("trailer": indicadores de información adicional, como Firmado por y Coautor). Es posible filtrar etiquetas tanto por clave como por valor, por ejemplo:
    "git log --pretty="%(trailers:key=Revisado por,valueonly)";

  • Se ha agregado un nuevo motor de seguimiento, Trace2, que ofrece un formato de salida más flexible y estructurado. Trace2 le permite recopilar telemetría sobre las operaciones ejecutadas y datos de rendimiento para un análisis y depuración más detallados (el usuario asigna el controlador, no se envían datos externamente);
  • El informe "git bisect" se ha hecho más legible, en el que las confirmaciones problemáticas ahora se resaltan más claramente y se muestran estadísticas resumidas sobre los cambios para cada archivo (al nivel del número de líneas modificadas);
  • Se ha rediseñado la heurística para determinar los cambios de nombre de los directorios para eliminar la instalación falsa de etiquetas de cambio de nombre. En caso de duda, dichos directorios ahora se marcan como conflictivos;
  • Se muestra una advertencia cuando intenta instalar una etiqueta en otra etiqueta, lo que generalmente se hace por error y puede llevar a configurar la etiqueta en una confirmación incorrecta (por ejemplo, una construcción como “git tag -f -m “mensaje actualizado” my-tag1 my-tag2″ resultará en la creación de una etiqueta en la etiqueta anterior, mientras que el desarrollador esperaba que la nueva etiqueta se instalara en la confirmación señalada por la etiqueta anterior);
  • La generación está habilitada para repositorios de mapas de bits (estructura de "mapas de bits de accesibilidad" basada en disco), que almacenan datos sobre conjuntos de objetos disponibles para cada confirmación y le permiten determinar rápidamente la presencia de un objeto base. Esta estructura reduce significativamente el tiempo de ejecución de las operaciones de recuperación de datos (git fetch).

Fuente: opennet.ru

Añadir un comentario