Si alguna vez ha trabajado en una gran base de código con un modelo de desarrollo distribuido, probablemente haya escuchado a la gente decir cosas como "Sue acaba de enviar un parche" o "Rajiv está comprobando la diferencia". Tal vez esos términos eran nuevos para usted y se preguntaba qué significaban. El código abierto ha tenido un impacto aquí, ya que el principal modelo de desarrollo de grandes proyectos desde el servidor web Apache hasta el kernel de Linux han sido proyectos de desarrollo "basados en parches" a lo largo de su vida. De hecho, ¿sabía que el nombre de Apache se originó a partir del conjunto de parches que se recopilaron y cotejaron con el código fuente original del servidor NCSA HTTPd?
Puede pensar que esto es folclore, pero una captura temprana del sitio web de Apache afirma que el nombre se derivó de esta colección original de "parches"; por lo tanto APA tCH y servidor, que luego se simplificó a Apache.
Pero basta de curiosidades históricas. ¿Qué son exactamente estos parches? y diferencias de los que hablan los desarrolladores?
Primero, por el bien de este artículo, supongamos que estos dos términos hacen referencia a lo mismo. "Diff" es simplemente la abreviatura de "diferencia"; una utilidad de Unix con el mismo nombre revela la diferencia entre uno o más archivos. Veremos un ejemplo de utilidad diff a continuación.
Un "parche" se refiere a una colección específica de diferencias entre archivos que se pueden aplicar a un árbol de código fuente utilizando la utilidad Unix diff. Entonces podemos crear diferencias (o parches) usando la herramienta de diferencias y aplicarlos a una versión sin parches de ese mismo código fuente usando la herramienta de parches. Aparte (y rompiendo mi regla de no más trivia de historia), la palabra "parche" proviene de la cubierta física de los agujeros de las tarjetas perforadas para hacer cambios de software en los primeros días de la informática, cuando las tarjetas perforadas representaban el programa ejecutado por el procesador de la computadora. La siguiente imagen, que se encuentra en esta página de Wikipedia que describe los parches de software, muestra este concepto original de "parche":
Ahora que tiene una comprensión básica de los parches y las diferencias, exploremos cómo los desarrolladores de software usan estas herramientas. Si no ha utilizado un sistema de control de código fuente como Git o Subversion, prepararé el escenario para la forma en que se desarrollan la mayoría de los proyectos de software no triviales. Si piensa en la vida de un proyecto de software como un conjunto de acciones a lo largo de una línea de tiempo, puede visualizar los cambios en el software, como agregar una característica o una función a un archivo de código fuente o corregir un error, que aparecen en diferentes puntos en la línea de tiempo, con cada punto discreto que representa el estado de todos los archivos de código fuente en ese momento. Llamaremos a estos puntos de cambio "confirmaciones", utilizando la misma nomenclatura que utiliza la herramienta de control de código fuente más popular de la actualidad, Git. Cuando desee ver la diferencia entre el código fuente antes y después de una determinada confirmación, o entre muchas confirmaciones, puede usar una herramienta para mostrarnos las diferencias.
Si está desarrollando software utilizando esta misma herramienta de control de código fuente, Git, es posible que tenga cambios en su sistema local que desee proporcionar para que otros puedan agregarlos como confirmaciones en su propio árbol. Una forma de proporcionar cambios locales a otros es crear una diferencia de los cambios de su árbol local y enviar este "parche" a otros que están trabajando en el mismo código fuente. Esto permite que otros parcheen su árbol y vean el árbol de código fuente con sus cambios aplicados.
Linux, Git y GitHub
Este modelo de compartir archivos de parches es cómo opera la comunidad del kernel de Linux con respecto a los cambios propuestos hoy. Si observa los archivos de cualquiera de las listas de correo populares del kernel de Linux (LKML es la principal, pero otras incluyen linux-containers, fs-devel, Netdev, por nombrar algunas), encontrará muchos desarrolladores que publican parches que deseo que otros revisen, prueben y posiblemente traigan al árbol Git del kernel oficial de Linux en algún momento. Está fuera del alcance de este artículo discutir Git, el sistema de control de código fuente escrito por Linus Torvalds, con más detalle, pero vale la pena señalar que Git habilita este modelo de desarrollo distribuido, lo que permite que los parches vivan por separado de un repositorio principal, empujando y tirando de diferentes árboles y siguiendo su flujo de desarrollo específico.
Antes de continuar, no podemos ignorar el servicio más popular en el que los parches y las diferencias son relevantes:GitHub. Dado su nombre, probablemente pueda adivinar que GitHub se basa en Git, pero ofrece un flujo de trabajo basado en web y API en torno a la herramienta Git para el desarrollo de proyectos de código abierto distribuido. Una de las formas principales en que los parches se comparten en GitHub no es por correo electrónico, como el kernel de Linux, sino mediante la creación de una solicitud de extracción. . Cuando confirma cambios en su propia copia de un árbol de código fuente, puede compartir esos cambios creando una solicitud de extracción en un repositorio compartido comúnmente para ese proyecto de software. GitHub es utilizado por muchos proyectos de código abierto activos y populares en la actualidad, como Kubernetes, Docker, Container Network Interface (CNI), Istio y muchos otros. En el mundo de GitHub, los usuarios tienden a usar la interfaz basada en la web para revisar las diferencias o los parches que componen una solicitud de extracción, pero aún puede acceder a los archivos de parche sin procesar y usarlos en la línea de comando con la utilidad de parche.
Poner manos a la obra
Ahora que hemos cubierto parches y diferencias y cómo se usan en comunidades o herramientas populares de código abierto, veamos algunos ejemplos.
El primer ejemplo incluye dos copias de un árbol de fuentes y una tiene cambios que queremos visualizar usando la utilidad diff. En nuestros ejemplos, veremos las diferencias "unificadas" porque esa es la vista esperada para los parches en la mayor parte del mundo moderno de desarrollo de software. Consulte la página del manual de diferencias para obtener más información sobre las opciones y formas de producir diferencias. El código fuente original se encuentra en sources-orig y nuestra segunda base de código modificada se encuentra en un directorio llamado sources-fixed. Para mostrar las diferencias en un formato de diferencia unificado en su terminal, use el siguiente comando:
$ diff -Naur sources-orig/ sources-fixed/... que luego muestra la siguiente salida del comando diff:
diff -Naur sources-orig/officespace/interest.go sources-fixed/officespace/interest.go
--- sources-orig/officespace/interest.go 2018-08-10 16:39:11.000000000 -0400
+++ sources-fixed/officespace/interest.go 2018-08-10 16:39:40.000000000 -0400
@@ -11,15 +11,13 @@
InterestRate float64
}
+// compute the rounded interest for a transaction
func computeInterest(acct *Account, t Transaction) float64 {
interest := t.Amount * t.InterestRate
roundedInterest := math.Floor(interest*100) / 100.0
remainingInterest := interest - roundedInterest
- // a little extra..
- remainingInterest *= 1000
-
// Save the remaining interest into an account we control:
acct.Balance = acct.Balance + remainingInterest
Las primeras líneas de la salida del comando diff podrían necesitar alguna explicación:Los tres --- los signos muestran el nombre de archivo original; cualquier línea que exista en el archivo original pero no en el nuevo archivo comparado tendrá como prefijo un solo - para notar que esta línea fue "restada" de las fuentes. El +++ los signos muestran lo contrario:el nuevo archivo comparado y las adiciones encontradas en este archivo están marcadas con un solo + símbolo para mostrar que se agregaron en la nueva versión del archivo. Cada "trozo" (eso es lo que las secciones llevan el prefijo @@ se llaman) del archivo de parche de diferencia tiene números de línea contextuales que ayudan a la herramienta de parche (u otros procesadores) a saber dónde aplicar este cambio. Puede ver en la función de referencia de la película "Office Space" que hemos corregido (eliminando tres líneas) la codicia de uno de nuestros desarrolladores de software, que agregó un poco al cálculo de interés redondeado junto con un comentario a nuestra función .
Si desea que otra persona pruebe los cambios de este árbol, puede guardar esta salida de diff en un archivo de parche:
$ diff -Naur sources-orig/ sources-fixed/ >myfixes.patchAhora tiene un archivo de parche, myfixes.patch, que se puede compartir con otro desarrollador para aplicar y probar este conjunto de cambios. Un compañero desarrollador puede aplicar los cambios utilizando la herramienta de parches, dado que su directorio de trabajo actual se encuentra en la base del árbol del código fuente:
$ patch -p1 < ../myfixes.patch
patching file officespace/interest.go
Ahora el árbol de fuentes de su compañero desarrollador está parcheado y listo para compilar y probar los cambios que se aplicaron a través del parche. ¿Y si este desarrollador hubiera realizado cambios en interest.go por separado? Siempre que los cambios no entren en conflicto directamente, por ejemplo, cambiar las mismas líneas exactas, la herramienta de parche debería poder resolver dónde fusionar los cambios. Como ejemplo, se usa un archivo interest.go con varios otros cambios en el siguiente ejemplo de ejecución de parche:
$ patch -p1 < ../myfixes.patch
patching file officespace/interest.go
Hunk #1 succeeded at 26 (offset 15 lines).
En este caso, el parche advierte que los cambios no se aplicaron en la ubicación original del archivo, sino que se compensaron con 15 líneas. Si ha cambiado mucho los archivos, el parche puede dejar de intentar encontrar dónde encajan los cambios, pero proporciona opciones (con las advertencias necesarias en la documentación) para activar la "borrosidad" coincidente (que está más allá del alcance de este artículo) .
Si usa Git y/o GitHub, probablemente no usará las herramientas diff o patch como herramientas independientes. Git ofrece gran parte de esta funcionalidad para que pueda usar las capacidades integradas de trabajar en un árbol de código fuente compartido fusionando y extrayendo los cambios de otros desarrolladores. Una capacidad similar es usar git diff para proporcionar la salida de diferencia unificada en su árbol local o entre dos referencias cualesquiera (un identificador de confirmación, el nombre de una etiqueta o rama, etc.). Incluso puede crear un archivo de parche que alguien que no use Git pueda encontrar útil simplemente canalizando la salida de git diff a un archivo, dado que usa el formato exacto del comando diff que puede consumir el parche. Por supuesto, GitHub lleva estas capacidades a una interfaz de usuario basada en la web para que pueda ver los cambios de archivos en una solicitud de extracción. En esta vista, notará que es efectivamente una vista de diferencia unificada en su navegador web, y GitHub le permite descargar estos cambios como un archivo de parche sin formato.
Resumen
Ha aprendido qué son una diferencia y un parche, así como las herramientas de línea de comandos comunes de Unix/Linux que interactúan con ellos. A menos que sea un desarrollador en un proyecto que todavía usa un método de desarrollo basado en archivos de parches, como el kernel de Linux, consumirá estas capacidades principalmente a través de un sistema de control de código fuente como Git. Pero es útil conocer los antecedentes y las bases de las características que muchos desarrolladores usan a diario a través de herramientas de alto nivel como GitHub. Y quién sabe, pueden ser útiles algún día cuando necesite trabajar con parches de una lista de correo en el mundo de Linux.