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 versionado 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 hacia 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 central “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” de los “Lieutenants”. Para cada “Lieutenant” aplicamos el “Integration Manager” para los desarrolladores y el “Dictator” aplica el “Integration Manager” para los “Lieutenants”.

Es una de las fortalezas de GIT. Podemos trabajar localmente tanto como queramos antes de hacer un *push* al repositorio canónico. No dependemos de una conexión a Internet. Para lo único que necesitamos conectividad es para clonar un repositorio o hacer un push hacia el repositorio remoto. Todo el resto del trabajo es local.

Se puede interactuar con GIT de diversas maneras:

• GUI : Existen varios front-ends gráficos.
• Extensones : Agregan funcionalidades al entorno gráfico de mantenimiento de los archivos.
• CLI : Es la “Command Line Interface”, la vieja y querida CONSOLA. La forma más poderosa de usar GIT.

Retorno a página anterior