Una introducción al control de versiones y Git

¿Estás familiarizado con Documentos de Google? Bueno, si es así, es seguro asumir que está al tanto con la pequeña pestaña 'Historial de versiones' que permite a los escritores y las personas involucradas verificar y realizar un seguimiento de todos los cambios realizados en el documento. en cualquier momento dado. Una herramienta útil, ¿no?

Ahora imagine que en lugar de una hoja llena de párrafos, hay archivos llenos de cientos de líneas de códigos. Y a diferencia de un solo documento, hay toneladas de archivos diferentes, constantemente actualizados.

En un escenario como este, donde hay miles de líneas de códigos en juego y el resultado final, es decir, la aplicación móvil es de lo que depende el futuro de una empresa, se vuelve aún más importante tener un software que controle todos los cambios. hecho en los archivos de código.

Aquí es donde entra en escena un software de control de versiones.

¿Por qué es importante el control de versiones en el desarrollo de software?

Como sugiere el nombre, un software de control de versiones permite a los desarrolladores de aplicaciones móviles realizar un seguimiento de las diferentes versiones del ciclo de desarrollo del software y realizar cambios en ellas. Esta capacidad de rastrear todos los cambios que ocurren en el código y luego la opción de deshacer los cambios es lo que hace que el control de versiones sea una parte importante del proceso de una empresa de desarrollo de aplicaciones móviles que involucra a múltiples desarrolladores.

Ahora, cuando se trata de control de versiones, hay una serie de software disponible en el mercado en la actualidad. Veamos algunos de ellos –

Software disponible para control de versiones

Aunque en su Encuesta de GitLab, el líder de software distribuido encontró que el 98% de los usuarios utilizan las herramientas de código abierto de Git y más del 92% de los desarrolladores utilizan Git como lenguaje de control de versiones en el proceso de desarrollo de aplicaciones, hay un número de razones por las que los desarrolladores podrían considerar la alternativa de Git. Algunas de esas razones pueden variar desde: la estructura de precios de GitHub y el hecho de que Github se lanza tanto en iOS como en Android, una aversión a Octocat o un nivel de comodidad simple con el lenguaje de control de versiones que no es Git.

Cualquiera que sea su razón, aquí está la alternativa de Git para el control de versiones:

Ahora, incluso cuando hay una serie de alternativas disponibles para el Control de versiones y en Appinventiv, tenemos una experiencia de primera mano trabajando en muchas de ellas, debido a los diferentes requisitos de los clientes, de hecho somos parciales hacia Git. Déjame decirte por qué.

Por qué Appinventiv usa Git para el control de versiones

1. Por su velocidad del rayo

De todo el software de control de versiones del mercado, la velocidad a la que funcionan los elementos Git log y Commit no tiene comparación con ningún otro. Y cuando su equipo de desarrolladores está trabajando en una plataforma, se vuelve absolutamente necesario que el software sea rápido.

2. Para la capacidad de trabajar sin conexión

Cuando trabaja en un software que se basa en Internet, puede ser riesgoso cuando está en movimiento y pierde la conexión con el repositorio central. Pero, este no es el caso con Git. Con Git, puede realizar casi todas las tareas en su máquina local: confirmar, explorar el historial del proyecto, crear una rama o fusionar.

3. Para el Relieve Deshacer

Git viene con un comando 'deshacer' que te permite corregir y revertir todo el compromiso. De hecho, incluso te da la opción de restaurar la confirmación 'eliminada' a través de su opción Reflog.

4. Para la copia de seguridad

Cuando el equipo trabaja en Git, cada clon que el equipo tiene en su máquina viene con una copia de seguridad utilizable. Además de eso, casi todas las acciones de Git solo agregan los datos y no los eliminan.

5. Para hacer confirmaciones útiles

Cuando nuestro equipo de desarrolladores realiza un conjunto de cambios no relacionados (tomando algunas características de A, corrigiendo algunos errores en otro), puede ser muy difícil para los otros miembros del equipo entender lo que sucedió y puede ser difícil para ellos revertir Las características de A si está causando problemas.

Git resuelve este lío creando una confirmación granular. A través de su concepto de 'área de preparación', uno puede averiguar fácilmente qué cambios se incluirán en la siguiente confirmación, incluso cuando solo tiene que mirar líneas individuales.

Estas fueron las cinco razones principales por las que usamos Git aquí en Appinventiv. Ahora que hemos visto el por qué, es hora de ver el cómo. Cómo incorporamos Git en nuestro Proceso de control de versiones.

Vayamos a eso ahora.

Proceso de control de versiones al usar Git

Creación de repositorio

El objetivo de Git es administrar un conjunto de archivos, también conocido como Proyecto. Para hacer eso, Git guarda toda la información en una estructura de datos que se conoce como Repositorio. Un repositorio consta de los códigos fuente de la aplicación, los recursos y los conjuntos de datos. Básicamente, tiene todo lo que define el proyecto de la aplicación.

Ahora, hay dos formas de obtener un repositorio en Git. Puede usar un directorio local y convertirlo en un repositorio de Git usando la línea de comando o puede copiar un repositorio de Git ya cargado en el suyo.

Cuando crea un repositorio, generalmente tiene dos opciones: público y privado. El repositorio público es el que pueden ver otros desarrolladores usando Git y el privado, por otro lado, es el que solo pueden ver unas pocas personas.

Derivación

Al lado de Creación de repositorio está Ramificación. En una empresa como Appinventiv, donde en un momento dado más de 15 a 20 desarrolladores están trabajando en un proyecto, no es raro que los desarrolladores compartan el mismo código fuente y trabajen en él. Lo que sucede es que, mientras algunos desarrolladores están ocupados solucionando problemas, otros podrían estar implementando algunas funciones.

En una situación como esta, necesitamos un sistema que facilite el manejo de diferentes versiones de código en la misma base de código.

Aquí es donde Gitflow entra en escena. Gitflow es un marco utilizado para ramificar de manera sistemática y eficiente.

Antes de continuar con cómo funciona el proceso de ramificación en Gitflow, permítanme explicar el concepto con un ejemplo.

Supongamos que hay 5 desarrolladores en su equipo y están trabajando en el desarrollo de una aplicación similar a Instagram. Ahora, las características individuales de la aplicación, como Supongamos que Feed y Notificaciones, se indican como Módulo 1, Módulo 2 y así sucesivamente. Ahora estos diferentes módulos son ramas de desarrollo, que después de trabajar se fusionan con la rama principal o Master.

En el momento en que un desarrollador agrega una sucursal, crea una línea de desarrollo independiente, que aísla su trabajo del de los miembros de su equipo. Luego, las diferentes ramas se fusionan en la rama principal.

La ramificación es el método que permite a los miembros del equipo identificar todos los cambios que deben esperar y es lo que facilita el retroceso.

En nuestros proyectos, generalmente mantenemos estas ramas:

• Rama maestra
• Rama de desarrollo
• Rama característica
• Sucursal de liberación
• Correcciones rápidas y correcciones de errores

Cometer

Los cambios que realiza un desarrollador en el archivo individual se conocen como Confirmación. Los cambios o confirmación se agregan en el repositorio local y no en el servidor. A continuación, nuestros desarrolladores siguen el hábito de escribir un mensaje de confirmación, en el que se publica la descripción de la confirmación (cambios realizados en el archivo), para que otros desarrolladores también conozcan los detalles de los cambios realizados en el archivo.

Empujar

Cuando se compromete en el repositorio local de Git, lo que sucede a continuación es que los cambios se envían al servidor, lo que se conoce como Push .

Es bastante fácil enviar el historial de confirmaciones al servidor cuando usted es el único que trabaja en un archivo, pero en caso de que también haya otros desarrolladores involucrados en el proceso, tendrá que extraer los cambios antes de poder enviar su conjunto de comprometerse con Git.

A continuación, veremos lo que se hace en el paso Extraer cambio.

Solicitud de extracción

Cuando más de un desarrollador está trabajando en el mismo archivo, lo que sucede es que el otro desarrollador puede enviar algunos compromisos al servidor antes de que los envíe. Y cuando eso sucede, surge el conflicto (más sobre eso más adelante).

Para evitar cargar el mismo código base dos veces en el servidor, los desarrolladores primero extraen los cambios del repositorio y se aseguran de que los códigos sean diferentes. Ahora, generalmente, cuando dos o más desarrolladores trabajan en el mismo archivo y envían su confirmación al servidor, aparece la opción de 'Fusionar'.

Hablemos de Fusionar a continuación.

Unir

Fusionar es el paso en el que los desarrolladores asocian todas las sucursales primero entre sí y luego con la sucursal maestra o principal.

Cada vez que una entrega ingresa un comando Push, obtienen una opción Fusionar, que luego les pregunta la rama con la que les gustaría fusionar la confirmación.

Ahora, en la etapa de Fusión, la ocurrencia de Conflicto es muy común. El conflicto generalmente ocurre cuando las dos ramas que planea fusionar se cambiaron en la misma parte en el mismo archivo. Lo que sucede aquí es que Git no puede determinar qué versión debe usarse.

Cuando surge este problema de conflicto, Git ofrece dos resoluciones: automática y manual.

Como dice el nombre, uno es donde Git descubre el problema por sí mismo y, en el segundo, los desarrolladores tienen que hacerlo manualmente. En Appinventiv, nos centramos en la resolución manual de conflictos, ya que elimina incluso las mínimas posibilidades de que se produzcan errores.

Mientras usamos Git para controlar la versión de nuestro proceso de desarrollo de aplicaciones, lo que sucede simultáneamente es el seguimiento de problemas.

Dado que somos grandes seguidores de Agile y confiamos en Agile para nuestro proceso de desarrollo de aplicaciones móviles , entendemos la importancia de manejar múltiples procesos de desarrollo al mismo tiempo. Y con la función de seguimiento de problemas, se vuelve mucho más fácil para los evaluadores observar en tiempo real el código escrito y enviado al servidor Git.

Hacemos uso de la placa ZenHub para monitorear el flujo de trabajo en cada repositorio. El tablero nos permite realizar un seguimiento de la prioridad del cambio sugerido y también ayudar a los desarrolladores a actualizar sus comentarios en el tablero en tiempo real.