GIT como control de versiones

GIT como control de versiones

El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante. Si eres diseñador o desarrollador web freelance o trabajas para una agencia digital y quieres mantener siempre de forma segura la evolución de tus proyectos, deberás comenzar a trabajar con GIT como control de versiones.

¿Que es un repositorio GIT?

Cada vez el mundo del desarrollo del Software evoluciona mas rápido. Por ello que necesitamos trabajar con las mejores herramientas de la actualidad.

En esta entrada hablaré sobre los fundamentos iniciales de GIT como control de versiones., ya que es una herramienta imprescindible para poder desarrollar nuestro software entre los diferentes integrantes del equipo técnico que se ocupan de tales cometidos.

GIT es un control de versiones, existen otros como Subversión etc.

Pero y si trabajo solo, ¿también lo necesito?

Correcto, trabajar con un control de versiones significa trabajar con buenas prácticas. Aunque trabajes solo, es posible que quieras mantener un control total de los cambios que tu aplicación irá sufriendo. Claro está, si trabajas en equipo, no existe otra opción, pues todos y cada uno de lo integrantes del equipo aportará su granito de arena al proyecto, eso significa que todo el proyecto se deberá encontrar siempre en su versión mas evolucionada de forma accesible dentro de un servidor remoto.

Trabajando con repositorios remotos

Todos los cambios que se realizan en cada versión local de cada desarrollador web del proyecto, se deben de subir al servidor remoto para tener siempre accesible la versión mas actual del proyecto. De esta manera, cuando finaliza la jornada, todos los integrantes del equipo o los responsables, suben las ramas realizadas con los cambios al servidor central. Esto se define com hacer un «PUSH» al repositorio remoto. Con ello conseguimos que cuando un desarrollador comienza su jornada, solicita una comprobación de posibles cambios sufridos en el servidor remoto, si existen se los descarga y ya puede comenzar a codificar.

¿Cuales son los repositorios remotos mas conocidos para nuestros proyectos?

En la actualidad existen 2 que son los mas conocidos entre la comunidad de desarrolladores:

• Github
• Bitbucket

El primero de ellos es quizás el mas conocido, es gratuito siempre y cuando no te importe que el código fuente del proyecto esté de forma pública a la comunidad de desarrolladores. Si deseas que tu repositorio se encuentre de forma privada y por tanto sólo accesible al equipo de desarrollo seleccionado, deberás de abonar una cuota que ronda desde los 7€ a los 200€ mensuales en función del número de repositorios que necesites en una misma cuenta y el número de desarrolladores web que tendrán acceso al mismo.

La otra opción, Bitbucket. Está opción es totalmente gratuita (Con unas limitaciones) para trabajar con repositorios de forma privada. También tiene su versión de pago, pero sólo será necesario si el número de integrantes o repositorios en una misma cuenta se te queda corto.

Bajo mi punto de vista, según la opción que escojas para mantener tus repositorios, será buena con sus pros y contras.

Git-flow ¿Que es eso?

Implementar git-flow a nuestros proyectos significa trabajar con unas reglas o pautas de ramas de manera sistemática en todos nuestro repositorios. Es una buena práctica trabajar con git-flow ya que el equipo técnico podrá trabajar cómodamente con estas reglas sabiendo en cada momento en que rama debe de trabajar en función del tipo de tarea que se encuentre realizando.

A continuación citaré las diferentes ramas existentes para trabajar con git-flow y su finalidad.

Ramas master y develop

El trabajo se organiza en dos ramas principales:

• Rama master: cualquier commit que pongamos en esta rama debe estar preparado para subir a producción
• Rama develop: rama en la que está el código que conformará la siguiente versión planificada del proyecto

Cada vez que se incorpora código a master, tenemos una nueva versión estable.

Además de estas dos ramas, Se proponen las siguientes ramas auxiliares:

• Feature
• Release
• Hotfix

Cada tipo de rama, tiene sus propias reglas, que resumimos a continuación.

Feature

• Se originan a partir de la rama develop.
• Se incorporan siempre a la rama develop.
• Nombre: cualquiera que no sea master, develop, hotfix-* o release-*

Estas ramas son utilizadas para el desarrollo de nuevas características de nuestra aplicación. Una vez finalizadas se integran con la rama develop.

Release

• Se originan a partir de la rama develop
• Se incorporan a master y develop
• Nombre: release-*

Estas ramas son utilizadas para preparar nuestra nueva versión de producción. En estas ramas son realizados los últimos ajustes y son corregidos los últimos bugs antes de incorporar las mismas a la rama master.

Hotfix

• Se origina a partir de la rama master
• Se incorporan a la master y develop
• Nombre: hotfix-*

Esas ramas se utilizan para corregir errores y bugs en el código en producción. Funcionan de forma parecida a las Releases Branches, siendo la principal diferencia que los hotfixes no se planifican.

¿Necesitas ayuda para manejar GIT como control de versiones.? Contacta conmigo y te ofreceré un presupuesto personalizado.