Estoy aquí para hablarles sobre un comentario sobre la instalación y el uso de Git y GitFlow para la gestión de proyectos de desarrollo. Las estaciones de trabajo de desarrollo están bajo Windows (con servidores bajo Debian y Ubuntu). El cliente elegido para gestionar GitFlow es SourceTree que lo integra de forma nativa. Git vino a reemplazar a SVN como administrador de fuentes para diferentes proyectos. Aportó una comodidad innegable en la gestión de nuestros desarrollos.

Instalación de un repositorio Git de referencia local

La idea es instalar un repositorio principal (no estamos hablando realmente de un servidor con Git) localmente, para alojar nuestras fuentes, y no llamar a un repositorio externo, como a través de GitHub, por ejemplo. Así que instalamos Git en uno de los servidores. La instalación es bastante sencilla, aquí encontrarás un paso a paso por ejemplo . Este depósito se utilizará para hacer el puente entre el git instalado en las estaciones de trabajo de desarrollo, que impulsará las modificaciones del código, y la producción que se vinculará al git (los lanzamientos se realizarán solicitando la repatriación del maestro, vendremos volver a esto más tarde lejos).

Subiendo un primer proyecto a Git

Ahora vamos a subir un primer proyecto al repositorio de referencia. Este proyecto existe, pero aún no está versionado a través de Git. Para hacer esto, siga estos pasos:

• creando un repositorio vacío
• cargando fuentes en este repositorio

Para el primer punto, es bastante simple, debe ir a la máquina que aloja el repositorio de referencia de Git y escribir el siguiente comando:

que creará un repositorio vacío llamado «myProject».

Para cargar las fuentes en este proyecto, esta vez debe ir a la carpeta que contiene las fuentes y escribir las siguientes líneas (tendrá que instalar el paquete Git en esta máquina si aún no lo ha hecho):

La primera declaración inicializa Git. El segundo para agregar todo el contenido al administrador de versiones. El tercero para conectarse al repositorio de referencia (aquí llamado myGitServer, para ser reemplazado por el nombre o la IP). El cuarto para confirmar y el último para enviar al repositorio de referencia. Una vez que se realiza el envío, el repositorio de referencia ahora contiene las fuentes del proyecto.

Usando GitFlow con SourceTree

Una vez que se haya creado el repositorio, podrá cargarlo en SourceTree a través del botón «Clonar / Nuevo». Luego llegas a una primera ventana. Le pide la URL de su repositorio y la carpeta local (la que está en su computadora que luego cargará como proyecto en su IDE). La URL del repositorio será la creada en el capítulo anterior.

A continuación, puede hacer clic en «Clonar» para finalizar la conexión. Luego, deberá cargar el GitFlow, y esto se hará con el botón dedicado en la cinta. El primer clic en este botón, configurará las diferentes sucursales. De forma permanente en tu proyecto tendrás dos ramas:

• desarrollar (rama de desarrollo)
• maestro (industria de la producción)

Estas ramas luego se agregarán a las que crees durante tus desarrollos (volveremos a esto). Normalmente, no es necesario realizar cambios directos en las ramas de desarrollo y master. Para modificar el código y luego integrarlo en producción, tienes disponibles los distintos elementos de GitFlox:

• Características
• solución caliente
• Liberar

Features

Una característica corresponde a una nueva funcionalidad en el proyecto, cuyo desarrollo requerirá varios compromisos (por lo tanto, no una modificación inmediata sino un desarrollo a corto o mediano plazo, también volveremos a la noción de compromiso más adelante). Para crear una función, debe usar el botón «GitFlow», «Iniciar nueva función». Se abre un cuadro de diálogo:

Solo dale un nombre a esta característica (trata de ser lo más explícito posible en relación al desarrollo que tienes que hacer). Cuando haga clic en Aceptar, verá que aparece en la lista de sucursales, en la carpeta de funciones.

Es posible crear varias funciones en paralelo, abrir algunas y eliminarlas, por ejemplo, para hacer una prueba. Pasamos de una característica a otra haciendo doble clic en la lista de ramas sobre la característica que nos interesa. Tenga en cuenta que si luego modifica un archivo, se modificará en la función seleccionada (por lo que es muy importante posicionarse en la función correcta antes de codificar). Para codificar, siempre usas tu IDE habitual.

Por lo tanto, es posible tener varias funciones que funcionan en los mismos archivos, al pasar de una función a otra encontrará el estado del archivo tal como se modificó en la función (muy práctico por lo tanto). Tenga en cuenta que para el acceso simultáneo al mismo archivo modificado en dos funciones, deberá poder cambiar de una función a otra para confirmar o ocultar los archivos en cuestión (volveremos a esto un poco más adelante).

A medida que avanza el desarrollo, puede confirmar sus cambios. Tenga en cuenta que la confirmación solo afecta a la característica actual. Puede enviar el mismo archivo varias veces a una función a medida que se desarrolla. La confirmación en este marco es una imagen del archivo en la función. Si vienes de SVN, olvida la noción de compromiso tal como la conoces. Confirmar no tiene el efecto de empujar su código al repositorio remoto, sigue siendo exclusivamente local.

Para seguir los cambios y confirmar, deberá pasar por la pestaña «Estado del archivo» de SourceTree:

 

En esta pestaña, verá sus archivos creados (signo de interrogación azul), modificados (tres puntos amarillos) o eliminados (rojo) en la sección «archivos no preparados» (zona 1). Esta parte reúne para la función o la revisión actual todos los archivos que se han modificado y para los que aún no se ha realizado ninguna acción. Si se desea realizar un commit o stasher (corresponde a dejarlos de lado por el momento, se trata de archivos en un estado que aún no están listos para ser commiteados, pero cuyas modificaciones se desean conservar, habrá que hacerlo por ejemplo para pasar de uno característica a otra con cambios simultáneos no confirmados), deberá marcarlos (esto los moverá al área 2) y hacer clic en el botón confirmar o ocultar. Entonces será necesario en el área inferior ingresar un comentario de confirmación y hacer clic en el botón.

Si no desea mantener los cambios realizados, puede hacer clic con el botón derecho en el archivo y elegir «Descartar», lo que tendrá el efecto de devolverlo al estado anterior. La zona 3 también indica las modificaciones realizadas en el archivo.

Cuando haya terminado su función, estando posicionado en ella (por lo tanto, debe estar en negrita), puede a través del botón «GitFlow» elegir «Finalizar función». Finalizar la función tendrá dos efectos:

• esto impulsará los cambios a la rama de desarrollo (local)
• esto eliminará la característica

Si obtiene un error al cerrar la función, es probable que se trate de un archivo no confirmado o de un conflicto.
Una vez finalizada la función, tendrá las modificaciones en su rama de desarrollo local. Luego puede «empujar» estos cambios a la rama de desarrollo remota. En ese momento, las modificaciones no están en producción, pueden pasar con un lanzamiento.

HotFix

Un HotFix es una corrección de errores en producción, o una adición rápida de funciones que solo requiere una confirmación. El Hotfix se crea a través del botón «GitFlow», «Iniciar nuevo hotfix». De la misma manera que para una función, podrá desarrollar, confirmar las modificaciones y cerrar la revisión (mediante el botón «GitFlow», «Finalizar revisión»).

Los impactos de finalizar la revisión son diferentes a los de cerrar una función. Porque los cambios se envían directamente a la rama principal. Por lo tanto, empujar los cambios los empujará a la rama maestra remota (así como al desarrollo).

Release

Un lanzamiento permitirá integrar en la rama maestra las funciones que se han completado e integrado en la rama de desarrollo. Simplemente abra la versión (a través de gitflow) dándole un nombre (como 1.1.0) y cierre la versión. Luego, simplemente envíe los cambios al maestro remoto.

Poner en producción

Para poner su proyecto en producción, Git debe estar instalado en el servidor de producción y las fuentes deben estar vinculadas al repositorio. La producción en este caso está vinculada a la rama maestra remota.

Una vez que estos requisitos previos iniciales son buenos, de repente puede realizar sus desarrollos utilizando funciones o revisiones. Usted integra todo en la rama maestra local y lo empuja al control remoto (a través de push). Una vez que todo está en el control remoto, producción puede cargar la rama maestra remota con este simple comando (que se ejecutará desde la raíz del proyecto):

Actualización de su entorno

Para actualizar su entorno con las modificaciones que se encuentran en las sucursales remotas, puede hacer una «búsqueda». Verificará si hay cosas para recuperar, pero se hace automáticamente con regularidad. Y un «tirón» para recuperar los cambios.

Actualización de una feature

Si una característica lleva mucho tiempo en desarrollarse, puede ser interesante actualizarla periódicamente integrando las modificaciones del desarrollo. Esto evitará una brecha demasiado grande entre los dos y los posibles conflictos resultantes de esta brecha. Para hacer esto, mientras está posicionado en la función para actualizar (por lo tanto, está en negrita), haga clic una vez en desarrollar, haga clic con el botón derecho y elija «Combinar desarrollo en la rama actual».

Resumen de acciones por tipo

Resumen de la aprobación de una hotfix

Iniciar nueva revisión… desarrollo… mover archivos de «archivos no preparados» a «archivos preparados»… confirmar… finalizar revisión… empujar a SourceTree.
maestro de origen de extracción de git en producción

Resumen de pasar una feature

Iniciar nueva función… desarrollo… mover archivos de «archivos no preparados» a «archivos preparados»… confirmar… finalizar función… empujar a SourceTree.
Entonces será necesario hacer un lanzamiento que incluya esta función (con otras posiblemente) para pasarla a producción.

Resumen del paso de un release

El lanzamiento moverá el desarrollo al maestro. Entonces, tienes que hacer un nuevo lanzamiento, cerrar el lanzamiento y hacer un empuje, luego un origen de git pull en prod.