Git es un popular sistema de control de versiones. En él, el cambio atómico de uno o más archivos se denomina confirmación, y varias confirmaciones consecutivas se combinan en una rama. Las ramas se utilizan para implementar nuevas ideas (características).
Sucede que la idea resulta ser un callejón sin salida, el desarrollador se apaga de la manera incorrecta y es necesario volver a la versión original, para esto debe olvidarse de la nueva rama y cambiar al desarrollador principal o maestro , y luego continuar trabajando como si nada hubiera pasado. En este caso, el "disparo" se colgará para siempre, como el deseo de eliminarlo. Pero, ¿cómo eliminarlo si es parte de la historia? Este proceso muestra los esfuerzos del programador adicto al trabajo, aunque en vano. ¡Es más fácil informar a las autoridades, porque un resultado fallido también es un resultado!
Me apresuro a complacer: los desarrolladores de Git en la versión 3 introducirán un nuevo comando para cerrar tales ramas perdidas. Permítame recordarle que la versión actual actual es 2.21.0 .
¿Cómo utilizar este equipo, qué ofrece y qué piensan las empresas de TI? El artículo responde a estas y otras preguntas.
Descripción
Ahora puede cerrar una rama fallida con una de las confirmaciones anteriores. Los arcos de la falla son de color amarillo en las siguientes figuras.
Aquí commit 4 es el último para una función fallida. Estaba cerrado desde el 1 , y luego regresó al maestro y se fue hacia el otro lado, desde el commit 5 .
También puede bloquear el commit en sí mismo, creando así bucles :
Puede encerrarse en cualquier confirmación: Smart Git calculará la diferencia y combinará todo correctamente:
¿Cómo usarlo?
El comando merge no contiene cierres, ya que para el primer caso la rama se forjará rápidamente , y para el segundo no hará nada ( git already up to date ).
Para no cambiar el comportamiento anterior, los desarrolladores decidieron ingresar un comando para cerrar:
git closure -s $source_commit -d $dest_commit -m $message
El primer argumento -s $source_commit especifica el hash del commit desde el cual realizar el bucle, y el segundo, opcional -d $dest_commit , especifica el commit en el que el bucle debe cerrarse. Si está ausente, el cierre se produce en la rama de salida actual. El parámetro -m $message establece que el mensaje de cierre, como la failed feature, revert to origin . Sin embargo, la --allow-empty-message también está disponible, lo que permite confirmaciones sin texto del mensaje. Por defecto, Git permite exactamente un cierre para un par de confirmaciones. Para evitar esta limitación, la opción --allow-multiple-closures .
Después de ejecutar el comando, el git mismo calculará los cambios, y en la confirmación final, se verá doble diff: desde la base y las ramas finales. En general, esta es una diferencia n-dimensional, es decir, puede realizar el cierre tantas veces como desee. cerrar-confirmar es similar a fusionar-confirmar con la diferencia de que almacena varios mensajes, no uno.
Desafortunadamente, las GUI existentes para trabajar con Git aún no son totalmente compatibles con los cierres. La versión de vista previa de GitExtensions crea curvas como una fusión en lugar de un hermoso arco. Tenga en cuenta el nuevo Closure message Closure diff y los campos de Closure diff :
Vale la pena señalar que el equipo de closure siempre cambia la historia (¡Git, ahora Git es una máquina del tiempo completa!), Por lo tanto, ahora puede --force ramas solo con la opción --force , o con la opción segura --force-with-lease .
Las bases para ramas con bucles también están disponibles, sin embargo, la lógica para contar las confirmaciones en ellas es complicada.
Además, la opción auto permite cerrar automáticamente todas las ramas antiguas. En este caso, la confirmación de cierre es aquella desde la que comenzó la ramificación. Usando complementos para el IDE de Git, los cierres se pueden ejecutar periódicamente. En GitExtensions, un complemento similar Eliminar ramas obsoletas elimina las ramas obsoletas.
Opinión de las empresas de TI.
Las grandes empresas de TI: Google, Facebook, Apple, DeepMind, Positive Technologies, y especialmente Microsoft, esperan cierres, porque ahora será posible formalizar el ciclo de vida de las sucursales, incluidas las no contiguas.
Uno de los principales gerentes de Microsoft, Michael Richter, escribe :
La nueva característica del git ciertamente reducirá el caos en el mundo del desarrollo de código abierto y no solo. Nuestros repositorios tienen muchas ramas colgantes. Por ejemplo, hay más de 200 en vscode , ¡y hay más de 300 en TypeScript ! Y este no es solo el problema de Microsoft. Los cierres no solo mejoran la organización, sino que también le permiten seguir el razonamiento del programador, a veces completamente incomprensible incluso para los colegas :) Los cierres me recordaron la película "Regreso al futuro", donde los personajes viajaron al pasado y al futuro. Me encanta esta película, la revisé varias veces. Y creo que amaré al git por esto aún más :)
Nota
Si anteriormente el gráfico de confirmación era un gráfico acíclico dirigido (DAG), entonces los cierres lo extienden a un gráfico dirigido generalizado. Con Git, será posible describir expresiones regulares en las que los estados son confirmaciones, y el alfabeto es el conjunto de todos los mensajes. Pero esto huele al centro de "programación anormal", y por lo tanto está más allá del alcance del artículo. Sin embargo, si está interesado en esto, consulte el artículo que describe cómo puede almacenar árboles genealógicos dentro de Git.