Cambiamos a MQL5 Algo Forge (Parte 2): Trabajando con varios repositorios

Introducción

En el primer artículo, comenzamos la transición desde el uso de MQL5 Storage (el almacenamiento SVN incorporado en el MetaEditor) a una solución más flexible y moderna basada en el sistema de control de versiones Git: MQL5 Algo Forge. La razón principal de este paso fue el deseo de usar plenamente diferentes ramas del repositorio mientras se trabaja en diferentes proyectos o funcionalidades dentro de un mismo proyecto.

La transición comenzó con la creación de un nuevo repositorio en MQL5 Algo Forge y la configuración de un entorno de desarrollo local usando Visual Studio Code, las extensiones pertinentes para trabajar con MQL5 y Git, así como la instalación de las herramientas necesarias. A continuación, añadimos un archivo .gitignore al repositorio creado para excluir los archivos estándar y temporales del seguimiento. Todos los proyectos actuales se cargaron en una rama archive independiente, a la que se asignó la función de repositorio de archivo de todo el código existente. La rama principal main se dejó vacía y se preparó para la organización de nuevas ramas de proyectos. De esta forma, se sentaron todas las bases necesarias para la posterior distribución de código de distintos proyectos a distintas ramas del repositorio.

Sin embargo, desde la publicación del artículo anterior, se han producido cambios significativos en el desarrollo del soporte de MetaEditor para el nuevo repositorio. Y esto nos obliga a replantearnos nuestro plan de utilización del nuevo repositorio. Así que en este artículo, nos alejaremos un poco de lo que creamos en el artículo anterior y veremos un ejemplo de creación de un proyecto público que utilizará otros proyectos públicos como bloques de construcción. El proyecto creado se dedicará al tema del desarrollo de asesores multidivisa. Como parte del trabajo en este proyecto, ya hemos escrito varios artículos que esbozan diferentes enfoques para desarrollar y modificar el código programático. Ahora intentaremos aprovechar al máximo el sistema de control de versiones de Git para organizar y agilizar el proceso de desarrollo.

Trazando el camino

Da miedo pensarlo, pero en el momento de escribir el último artículo sobre este tema, el MetaEditor todavía carecía de la opción "Git" del menú principal y de los comandos del menú contextual para trabajar con el repositorio MQL5 Algo Forge. Por ello, invertimos bastante esfuerzo en construir un proceso de trabajo con el nuevo repositorio utilizando herramientas de terceros como Visual Studio Code. Como aún no sabíamos cómo se implementaría el soporte de repositorios en el MetaEditor, tuvimos que utilizar lo que teníamos en ese momento.

Ha pasado el tiempo, ahora las nuevas versiones de MetaEditor ya soportan el trabajo con el nuevo repositorio, y recientemente se ha publicado un nuevo artículo de MetaQuotes "Cómo empezar a trabajar con MQL5 Algo Forge", en el que se muestran los puntos principales y las posibilidades de uso de MQL5 Algo Forge. Sin embargo, lo más importante, a nuestro juicio, es la implementación del soporte para el mecanismo de proyectos compartidos (Shared Projects) en el MetaEditor.

Vamos a explicar qué tiene de significativo. Antes del lanzamiento de esta implementación, sabíamos que la carpeta MQL5 sería ahora un único repositorio almacenado en los servidores GIT de MQL5 Algo Forge. Aparentemente, este repositorio tendrá el nombre fijo de mql5. Es decir, distintos usuarios tendrán un repositorio llamado mql5 en el repositorio MQL5 Algo Forge. Precisamente este repositorio se clonará en la carpeta MQL5 tras instalar un nuevo terminal, autorizar al usuario en Community y conectar el repositorio. Sin embargo, en el repositorio MQL5 Algo Forge inicialmente era posible crear repositorios adicionales. Siendo exactos, no eran adicionales, sino simplemente otros repositorios no relacionados con el repositorio mql5 de ninguna manera. Por lo tanto, nos surgió naturalmente la pregunta: ¿cómo sería posible trabajar con ellos en el MetaEditor? 

¿Quizás añadiendo la posibilidad de seleccionar el repositorio utilizado en cada copia específica instalada de terminal? ¿O eso tampoco ocurrirá? Entonces tendremos que conformarnos con un solo repositorio, pero al menos en este repositorio podremos crear diferentes ramas que pueden utilizarse para distribuir el trabajo en diferentes proyectos. Para ser sinceros, nos orientábamos en este escenario, el menos positivo. Y es el peor porque, después de todo, diferentes ramas en un repositorio no resultan muy cómodas para trabajar en diferentes proyectos. Afortunadamente, los temores no se hicieron realidad.

MetaQuotes ofrecía otra forma bastante elegante de matar dos pájaros de un tiro. Por un lado, se mantiene el repositorio principal denominado mql5. Su uso vendrá bien a aquellos que hayan utilizado MQL5 Storage anteriormente. Ahora será igual de fácil seguir utilizando un sistema de control de versiones sin prestar demasiada atención a qué sistema de control de versiones (CVS) subyace.

Por otro lado, todos los demás repositorios de usuario parecen estar disponibles como carpetas dentro de Shared Project. Así, obtenemos una nueva carpeta raíz estándar, junto con las carpetas similares existentes (MQL5, MQL5/Experts, MQL5/Include etc.), destinada a almacenar el código de otros repositorios de usuario.

Vamos a simular la siguiente situación: supongamos que tenemos dos repositorios separados en el nuevo repositorio MQL5 Algo Forge que no son los repositorios principales por defecto. Uno de ellos (Adwizard) contendrá solo código de biblioteca, es decir, contiene solo archivos *.mqh y ningún archivo *.mq5 que se convertiría en un asesor experto (o, por ejemplo, un indicador) al compilarse. El segundo repositorio (Simple Candles) ya contendrá archivos *.mq5 que utilizarán los archivos del primer repositorio como archivos de inclusión. Para mayor brevedad, nos referiremos al primer repositorio como el repositorio de la biblioteca y al segundo como el repositorio del proyecto.

Queremos ver cómo debemos proceder para asegurarnos de que el código del repositorio de la biblioteca se utilice al conducir desarrollos en el repositorio de proyectos. Esta situación podría generalizarse si, por ejemplo, los códigos publicados por los miembros de la comunidad en Codebase son duplicados por ellos en MQL5 Algo Forge como repositorios públicos. A continuación, para conectar uno o más repositorios como bibliotecas de código de terceros, para nuestro proyecto puede implementarse como intentaremos hacer dentro de este artículo.

Comencemos

En primer lugar, vamos a ver la situación desde el punto de vista del desarrollador de estos repositorios. Es decir, podemos editar fácilmente el código en ambos repositorios según necesitemos, sin esperar a las revisiones y la aceptación a través del mecanismo Pull Request. Luego crearemos una carpeta del terminal limpia y copiaremos dos archivos de cualquier copia previamente instalada del terminal MetaTrader 5:

Para evitar la búsqueda de la carpeta de trabajo del terminal entre los escombros del sistema de archivos, le recomendamos que inicie el terminal en el modo Portable. Para Windows, una posible manera de hacerlo sería crear un acceso directo al archivo de terminal que se está ejecutando y, a continuación, añadir el modificador /portable a la línea de inicio en las propiedades del acceso directo. 

Después pondremos en marcha el terminal, abriremos una nueva cuenta demo por si acaso, actualizaremos el terminal a la última versión, nos autorizaremos en Community, y luego llamaremos al MetaEditor pulsando F4. Vamos a conectar el repositorio MQL5 Algo Forge, si no se ha conectado automáticamente todavía.

Podemos ver que en el navegador aparece la carpeta Shared Projects, donde podemos ver los nombres de todos los demás repositorios que hemos creado previamente a través de la interfaz web. Sin embargo, si abrimos esta carpeta en el explorador, estará vacía. Es decir, todavía no habrá archivos reales de otros repositorios en nuestra computadora.

Ahora haremos clic con el botón derecho en los nombres de los dos repositorios que nos interesen y seleccionaremos "Clonar repositorio Git" en el menú contextual. Veremos los mensajes de registro sobre la clonación exitosa de los repositorios Adwizard y Simple Candles. En el explorador, después de esta operación, también podremos ver las carpetas con los repositorios clonados:

Así pues, el código programático de ambos proyectos se ha descargado en nuestra computadora y está listo para ser utilizado.

Y nos enfrentamos a nuestro primer problema

Intentamos abrir el archivo del asesor experto SimpleCandles.mq5 y compilarlo:

Como podemos ver, se producen errores durante la compilación. Vamos a averiguar sus causas. Sin duda, no son irresolubles ya que este código ya fue compilado con éxito en su momento. ¿Qué hemos cambiado ahora? Solo la disposición mutua de archivos de las partes de la biblioteca y del proyecto. Así pues, los dos primeros errores fundamentales se deben a que el compilador no encuentra los archivos de biblioteca donde espera que estén. En la parte 28, acordamos utilizar esta estructura de carpetas para almacenar la biblioteca y las partes del proyecto:

Es decir, el repositorio de bibliotecas se encontraba dentro de una subcarpeta del repositorio de proyectos. Esto fue en gran medida un movimiento forzado para tener alguna certeza sobre dónde se encontraría los archivos de la biblioteca. Ahora vamos a cambiar esa disposición. En lugar de la subcarpeta obligatoria Include dentro de la carpeta del proyecto, usaremos la carpeta MQL5/Shared Projects. Esperamos que siga en su sitio y no cambie en un futuro próximo su finalidad actual.

Para ello, tendremos que introducir cambios en dos lugares donde hay comandos para conectar los archivos de biblioteca. Pero antes de eso, nos valdremos de una buena práctica de desarrollo según la cual los cambios en el código del proyecto que resuelvan un problema independiente se realizarán en una rama separada del repositorio. Y después de depurar y lograr el resultado deseado, la rama separada se fusionará con la rama principal.

Veamos qué ramas tenemos ya en el repositorio del proyecto. Esto puede hacerse de varias formas:

• A través del menú contextual de la carpeta del repositorio en el MetaEditor: 

• A través de la interfaz web del repositorio en la página de las ramas del repositorio seleccionado:

• A través de una herramienta de terceros que pueda trabajar con repositorios Git, por ejemplo, Visual Studio Code. Frente al nombre del repositorio se encuentra el nombre de la rama main actual. Al hacer clic en él, veremos una lista de las ramas disponibles (y elementos de menú para crear nuevas ramas):

Así, ahora tendremos cuatro ramas en el repositorio:

• main es la rama principal. Se crea al crearse el repositorio. En el caso más simple, salvo esta rama, no podemos crear ramas adicionales, y hacer todo el desarrollo en la rama principal. En un caso más complejo, esta rama se puede usar para almacenar el estado de los archivos que proporcionan una versión estable del código en esta etapa. Cualquier cambio que aún no esté totalmente implementado y probado deberá implementarse en otras ramas.
• develop es una rama de desarrollo. Nuevamente, en el caso más simple, podemos usar solo una de estas ramas para hacer ediciones y añadir nuevas funcionalidades al proyecto. Esta opción resultará suficiente si la adición de nuevas funciones se realiza de forma estrictamente secuencial. Es decir, no empezaremos a implantar nuevas funcionalidades hasta que hayamos llevado el proyecto a un estado totalmente funcional tras añadir las innovaciones anteriores. Antes de empezar a trabajar en una nueva funcionalidad, se fusionarán las ramas: las ediciones realizadas en la rama de desarrollo se fusionarán en la rama main. En un caso más complejo que implique trabajar simultáneamente en varias novedades incesantes, resulta incómodo trabajar en una única rama de desarrollo. Por consiguiente, podemos crear ramas separadas para cada parte aislada de la nueva funcionalidad.
• article-17608-close-manager y article-17607 son precisamente ramas de este tipo. La primera de ellas contiene ediciones que añaden un módulo gestor para cerrar posiciones cuando se alcanza un beneficio o una pérdida concretos. Esta rama se ha incluido en develop, y después de eso, develop se incluye en main, mientras que la otra rama contiene ediciones relativas a la modernización del mecanismo de optimización automática, y aún no se ha completado, es decir, sus ediciones aún no han llegado ni a develop ni a main.

Insistamos de nuevo en que usar un repositorio Git no nos obliga a seguir ninguna regla para crear y utilizar diferentes ramas. En este sentido, tenemos total libertad para elegir la opción que más nos convenga. Simplemente algunos patrones de trabajo con ramas le parecieron muy convenientes a alguien, y este compartió sus técnicas con otros desarrolladores a los que también les gustaron. Así es como poco a poco van tomando forma las llamadas "buenas prácticas" (best practices). Pero puede haber muchas diferentes, y la elección de cuáles utilizar depende del proyecto y del desarrollador o desarrolladores concretos. A modo de comparación, podemos ver, por ejemplo, uno de los principios sugeridos para crear ramas en este artículo.

Pero volvamos a las ramas de nuestro repositorio.

Cabe preguntarse qué significa el prefijo origin/ o, como aparece en el MetaEditor, refs/remotes/origin/. Esto supone solo una indicación de que esta rama ya está presente en el almacenamiento del repositorio remoto, no solo en el equipo local. Normalmente intentamos mantener sincronizadas las ramas local y remota. El MetaEditor nos obliga literalmente a hacerlo: al seleccionar el comando Commit del menú contextual, se ejecuta automáticamente el comando Push para enviar el commit al repositorio remoto.

Si no utilizamos la interfaz del MetaEditor para la confirmación, podemos confirmar los cambios solo localmente, sin enviarlos a un repositorio remoto. En este caso, una rama con el mismo nombre se encontrará en diferentes estados en el repositorio local y en el remoto. El mencionado prefijo origin/ es necesario para poder especificar exactamente con qué rama queremos hacer algo. Si hay una, nos referiremos a una rama en el repositorio remoto, y si no, nos referiremos a una rama en el repositorio local.

Creando una nueva rama

Como los cambios previstos en el código solo se refieren a la garantía de su compilabilidad después de cambiar la ubicación de la parte de la biblioteca, realizaremos estos cambios en una nueva rama generada a partir de develop. Para ello, tendremos que cambiar a la rama origin/develop, después de lo cual aparecerá en la lista como la rama local develop:

A continuación, podemos elegir crear una nueva rama (New) e introducir el nombre deseado. Nos ceñiremos al acuerdo previamente aceptado de que los nombres de las ramas que se crean para un artículo concreto, lleven la palabra artículo al principio del nombre, seguida del identificador numérico único del artículo tras un guión. Además, podemos añadir al nombre una parte arbitraria que refleje el tema del artículo. Así que crearemos una rama llamada "article-17698-forge2".

También podríamos haber creado la rama de otras formas: usando la interfaz web, la interfaz de Visual Studio Code o la interfaz de línea de comandos. En este último caso, solo tendremos que ejecutar este comando en la carpeta raíz del repositorio:

git checkout -b article-17698-forge2 develop

Es decir, estamos pidiendo a Git que compruebe una nueva rama (-b) llamada article-17698-forge2 generada a partir de la rama llamada develop.

Si creamos una rama, pero no a través de la interfaz web, solo existirá en nuestra computadora local hasta que realicemos el primer envío de cambios al repositorio superior (Push). Lo contrario también es cierto: si una rama ha sido creada en el repositorio upstream a través de la interfaz web, entonces hasta la primera vez que recibamos los cambios del repositorio upstream (Pull), esa rama no estará en nuestro computadora local.

Para enviar estos cambios, podemos hacer lo siguiente:

o esto:

El comando de consola para una operación Push que se supone que envía cambios que implican la creación de una nueva rama deberá tener necesariamente parámetros adicionales para confirmar que realmente queremos crear también una nueva rama en el repositorio upstream:

git push --set-upstream origin article-17698-forge2

Después de eso, la rama existirá tanto en la copia local del repositorio como en el repositorio anterior en el almacenamiento MQL5 Algo Forge. Podemos empezar a editar sin miedo a estropear el código de otras ramas.

Correcciones

Las modificaciones necesarias serán muy simples. En el archivo SimpleCandles.mq5, cambiaremos la línea que conecta el archivo desde la biblioteca Adwizard. Las carpetas raíz de los repositorios Simple Candles y Adwizard estarán ahora en el mismo nivel dentro de la carpeta Shared Projects, por lo que para llegar al archivo Expert.mqh, primero deberemos subir un nivel (../) y luego bajar a las subcarpetas del repositorio de biblioteca:

#include "Include/Adwizard/Experts/Expert.mqh"
#include "../Adwizard/Experts/Expert.mqh"

El archivo Strategies/SimpleCandlesStrategy.mqh necesitará una corrección similar:

#include "../Include/Adwizard/Virtual/VirtualStrategy.mqh"
#include "../../Adwizard/Virtual/VirtualStrategy.mqh"

Después de estos cambios, el asesor experto SimpleCandles.mq5 volverá a compilarse correctamente. Ahora podemos fijar los cambios (Commit) en el repositorio:

Como ya hemos mencionado, este método de commit ejecuta automáticamente el comando Push, que envía los cambios realizados al repositorio superior en el almacenamiento MQL5 Algo Forge.

Si trabajamos usando comandos de consola, podemos conseguir el mismo resultado de la siguiente manera. Si no solo se han realizado cambios en archivos existentes, sino que también se han creado nuevos ficheros, antes deberemos ejecutar la orden de adición de nuevos ficheros al índice del repositorio:

git add .

Este comando añade al índice todos los archivos nuevos encontrados en la carpeta del repositorio. Si en este comando indica nombres de archivo concretos en lugar de un punto (.), solo se añadirán éstos. Y luego ejecutaremos el comando para confirmar los cambios con el comentario especificado y el comando para enviar los cambios a un repositorio superior:

git commit -m "Fix relative paths to include files from Adwizard"
git push

Con esto daremos por completados los cambios en la rama article-17698-forge2, ahora puede fusionarse con la rama develop y cerrarse.

Topamos con el segundo problema

Y aquí es donde nos llevamos una sorpresa desagradable. El MetaEdior aún no dispone de herramientas que permitan realizar la fusión de ramas. Es decir, podemos crear nuevas ramas, pero no podemos transferir los cambios realizados de una rama a otra. Esperemos que esta funcionalidad se añada en un futuro próximo, pero mientras tanto tendremos que recurrir a herramientas alternativas para realizar acciones en el repositorio.

Tenemos dos formas principales de realizar una fusión de ramas. La primera es usar la interfaz de fusión de ramas de Visual Studio Code o los comandos de consola. Por ejemplo, para la fusión que necesitamos, bastará con ejecutar los siguientes comandos:

git checkout develop
git pull
git merge --no-ff article-17698-forge2

Primero cambiamos a la rama develop y luego la actualizaremos por si acaso (por si se han hecho algunas ediciones que aún no hayan llegado a nuestro computadora local). El último comando realizará la fusión real de la rama actual. En el último paso, es posible que surjan conflictos de fusión, pero en nuestra situación es bastante improbable que se produzcan, ya que seguiremos considerando la opción de trabajar en un solo proyecto. Así que, incluso si trabaja desde distintos lugares, pero se acuerda de actualizar periódicamente los repositorios al estado actual, no debería haber conflictos.

Sin embargo, no vamos a centrarnos en los matices de este método, sino que estudiaremos el segundo con más detalle. Para ello, necesitaremos usar la interfaz web del repositorio MQL5 Algo Forge.

Usaremos Pull Request para la fusión

Junto con otros repositorios basados en Git (como GitHub, GitLab, Bitbucket), el repositorio MQL5 Algo Forge también posee un mecanismo llamado Pull Request (PR).

Pull Request (PR) es un mecanismo que permite a un desarrollador sugerir que los cambios que ha realizado se incluyan en algún repositorio. Es decir, la creación de un PR es una forma de notificar al propietario del repositorio y a otros implicados en el desarrollo: "He hecho el trabajo en mi rama, por favor 'saque' (pull) estos cambios a la rama principal (main/master/develop) después de la comprobación".

El PR no es una característica de Git en sí, es un complemento externo que organiza el proceso de revisión y discusión del código antes de que se realicen cambios en la rama principal del repositorio.

Los PR suelen abordar otras tareas críticas del desarrollo moderno, como la integración continua (CI) con ejecuciones automáticas de pruebas, el control de calidad por parte de otros desarrolladores y la documentación de los cambios como comentarios en los PR que explican por qué se han introducido determinados cambios en el proyecto. Sin embargo, todo esto será más relevante para proyectos en los que varios desarrolladores trabajen en el código simultáneamente, mientras que los proyectos que utilizan MQL5 suelen ser individuales. Quizá en el futuro algunos proyectos se conviertan en proyectos grupales, pero hasta ahora no hemos visto ningún ejemplo vívido de tales proyectos.

No obstante, acabamos de reproducir el principio de un flujo de trabajo típico para añadir nuevas funcionalidades o realizar correcciones utilizando PR:

1. Obtener los últimos cambios. Antes de empezar, actualizaremos la rama principal local de develop.

2. Crear una nueva rama para la tarea. A partir de la rama actual develop, crearemos una rama con el nombre claro article-17698-forge2.

3. Ejecutar el trabajo en la nueva rama: Corregir/añadir código a algunos archivos, probar, confirmar (commit) los cambios.

A continuación, debemos seguir los siguientes pasos.

4. Crear un Pull Request. Para ello, en la interfaz web del repositorio MQL5 Algo Forge, iremos a la pestaña con el nombre correspondiente y haremos clic en el gran botón rojo "New pull request":

A continuación, accederemos a la página de selección de las ramas del RP que deseamos crear. En esta fase aún no se ha creado, ya que primero tendremos que decidir a qué rama y desde qué rama queremos mover las ediciones. Seleccionando las ramas, podemos ver la composición de las ediciones a trasladar. Nuevamente, haremos clic en el botón "New pull request".

Se abrirá una página en la que podremos comentar los cambios realizados. Allí también podremos seleccionar a los desarrolladores que tendrán que comprobar las ediciones. Por defecto, nos enviaremos la solicitud de validación a nosotros mismos, que es exactamente lo que necesitamos.

5. El proceso de investigación y discusión. Nos saltaremos este paso, ya que nosotros mismos nos encargamos del desarrollo. Pero, en general, en este paso debería ocurrir lo siguiente:

   • Los revisores estudian el código y dejan comentarios (generales o específicos de una línea concreta);

   • El autor del RP responde a los comentarios y efectúa las ediciones necesarias directamente en el mismo hilo;

   • todos los nuevos push a una rama se añadirán automáticamente al PR existente.

6. Fusión. Una vez aprobado por los revisores (si los hay) y pasado por CI (también si los hay), el PR podrá cerrarse realizando una fusión. Suelen existir varias opciones para mover las ediciones a la rama de destino:

• Merge commit: crea una confirmación de fusión independiente. La historia se conserva tal cual.

• Squash and merge: todas los commits de la rama de PR se fusionan en una única confirmación, que se añade a la rama de destino. Una opción adecuada si no queremos atascar la historia con pequeños commits como "error tipográfico corregido".

• Rebase and merge: los commits de PR se trasladan a la parte superior de la rama de destino (en nuestro caso, develop). La historia resulta lineal y limpia.

De las opciones de fusión propuestas, elegiremos la primera, ya que queremos mantener todos los commits realizados en la historia. Así que haremos clic en el botón "Create merge commit":

Llegaremos a la página final del trabajo con Pull Request. Marquemos la opción "Delete branch ..." para cerrar inmediatamente nuestra rama de desarrollo temporal. En la historia de commits quedará que dicha rama ha existido. Sin embargo, no tendrá sentido dejar este hilo abierto, puesto que ya hemos alcanzado el objetivo fijado. Crearemos nuevas ramas para otros cambios que resuelvan otros problemas. Así, mirando la lista de ramas del repositorio en un momento dado, podremos hacernos una idea de en qué tareas se está trabajando actualmente en paralelo.

Todo lo demás de la página podrá dejarse como está y pulsar el botón "Create merge commit".

Esto completará el proceso de fusión: la rama article-17698-forge2 se fusionará con la rama develop y se eliminará:

En general, utilizar un Pull Request (PR) para fusionar ramas incluso en nuestro propio repositorio es una práctica buena y sólida, incluso si trabajamos en un proyecto en solitario. Antes de realizar la fusión, una vez más podremos revisar visualmente todos los cambios en la cómoda interfaz del repositorio MQL5 Algo Forge. Con una comprobación tan específica, a veces se pueden detectar cosas que han escapado a los commits: comentarios sobrantes, archivos añadidos accidentalmente, cambios subóptimos. En esencia, supone una forma de autodisciplina. Además, acostumbrarse a los procesos adecuados desarrolla el hábito de trabajar de esta manera (creación de una rama aparte, revisión del código, ...). Y si el lector tiene que trabajar en un equipo de desarrollo, no deberá reciclarse: el proceso ya estará afinado.

Así que sí, enviarse un PR a uno mismo no solo es posible, sino recomendable para cualquier proyecto más o menos serio. Esto mejorará la calidad del código y supone una muestra de disciplina. Aunque nadie nos impide hacer una fusión directa a través del comando git merge para correcciones rápidas de uno o dos commits. Pero para ediciones más amplias, es mejor usar un PR.

Conclusión

Bien, en general, ya nos hemos aclarado con el trabajo con los repositorios propios. Hemos pasado de clonar repositorios a perfeccionar el proceso de realización de ediciones que dejan el código en el repositorio en funcionamiento y listo para seguir desarrollándolo. Ahora es comprensible que un repositorio de proyectos pueda usar el código de otro (u otros) repositorios que actúen como repositorios de bibliotecas.

Sin embargo, solo hemos visto una parte: cuando el propietario de los repositorios del proyecto y de la biblioteca es el mismo. La otra cara es cuando el propietario del repositorio de un proyecto quiere usar los repositorios de otras personas como repositorios de bibliotecas. Aquí, por desgracia, no es tan sencillo, aunque esta forma de trabajar, es decir, el uso activo del código de otras personas y el trabajo colaborativo, se declaró como uno de los objetivos del cambio a un nuevo repositorio. Pero no vamos a hacer todo a la vez, lo importante es que hemos comenzado.

Por ahora, nos detenemos aquí, ¡hasta la próxima entrega!