Según la definición de Wikipedia

“Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación.”

Esta es una definición genérica de lo que significa el control de versiones. En nuestro caso, los productos que vamos a manejar son archivos digitales como por ejemplo:

• Programas.
• Diseños de cohetes realizados en OpenRocket.
• Diseños de piezas realizadas en OpenScad.
• Textos en general.
• y varios etc.

GIT es un sistema de versiones distribuido (descentralizado). Fue diseñado para correr de forma local en casi todas sus funcionalidades. No dependemos de un respositorio central y, por lo tanto, de acceso a internet para poder trabajar con nuestros dearrollos.

Veamos algunos conceptos y definiciones asociados al control de versiones con GIT:

Un repositorio canónico o bendecido es el respositorio que tiene la aprobación de los gerentes del proyecto como el estándard “de facto” desde donde se debe clonar su contenido para realizar las modificaciones.

El “branching” permite a los desarrolladores “clonar” un respositorio de trabajo e tal forma de poder jugar con su contenido sin temer a que se produzcan cambios dañinos para el desarrollo. El “branching” crea una copia del código tal cual está en ese momento en una rama (branch) separada para poder trabajr de forma segura. Siempre vamos a poder reconstruir el código original.

GIT maneja los envíos al repositorio (a esta operación se la denomina “commit”) usando un área intermedia llamada “staging area” o “index”. Esta forma de trabajo permite enviar un archivo a “staging”, seguir trabajando sobre el mismo archivo con una versión en “staging” que consideramos buena previo al envío al respositorio como versión definitiva de esa instancia del desarrollo. La “staging area” es un área de trabajo extra para poder guardar copias intermedias antes de decidir qué mando al repositorio. Me da la oportunidad de mantener un repositorio limpio de commits con mínimas modificaciones.

Tan importante como la herramienta de versionadp es el “workflow” (flujo de trabajo) que se diseñe para manejar los desarrollos. El “workflow” es independiente de la herramienta. Es el diseño de la forma de trabajo del grupo de desarrollo. GIT tiene la virtud de adaptarse a prácticamente cualquier tipo de “workflow”.

Vamos a ver 3 tipos de “workflow” habituales en desarrollo:

• CENTRALIZADO : Existe un sólo respositorio compartido desde y haci el cual se toman y depositan los códigos de los desarrolladores. Todos tiene la misma autoridad sobre el respositorio. Un desarrollador debe siempre clonar el respositorio localmente cada vez que deba trabajar. Realiza sus modificaciones y lo vuelca al repositorio central resolviendo los conflictos que encuentre. Este es un tema que lo veremos más adelante. Este “workflow” funciona para equipos pequeños de desarrolladores.
• INTEGRATION MANAGER: Es muy similar al CENTRALIZADO ya que hay un respositorio “bendecido” el cual todos usan como referencia. La diferencia radica en que hay solamente una persona que tiene derecho a hacer las subidas (“push”) al repositorio central. Es a esa persona que se le denomina “Integration Manager”. Los desarrolladores trabajan localemente con los clones del respositorio central. Luego hacen “push” a respositorios intermedios a los cuales tiene acceso el “Integration Manager”. Este revisa las modificaciones y las integra a su depósito local. Este trabajo lo hace con todas las modificaciones de todos los desarrolladores involucrados. Cuando considera que todo está bien, hace un “push” al respoitorio cental “bendecido” y el ciclo vuelve a comenzar.
• DIRECTOR AND LIEUTENANT: Es una extensión del anterior. Los “Lieutenants” son “Integration Manager” de secciones de desarrolladores que reportan al “Dictator” que a su vez funciona como un “Integration Manager” delos “Lieutenants”. Para cada “Lieutenant” aplicamos el “Integration Manager” para los desarrolladores y el “Dictator” aplica el “Integration Manager” para los “Lieutenants”.

Retorno a página anterior