Herramientas de usuario

Herramientas del sitio


acemu:articulos:articulos_tecnicos:software:git

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión
Revisión previa
acemu:articulos:articulos_tecnicos:software:git [2016/06/29 13:01]
tabare.perez
acemu:articulos:articulos_tecnicos:software:git [2016/07/08 17:20] (actual)
tabare.perez
Línea 1: Línea 1:
 +[[:ACEMU:Artículos:Artículos Técnicos:Software|Retorno a página anterior]]
 +
 +
 +----
 +
 ====== Tutorial básico de GIT (EN CONSTRUCCIÓN) ====== ====== Tutorial básico de GIT (EN CONSTRUCCIÓN) ======
 Según la definición de [[https://es.wikipedia.org/wiki/Control_de_versiones|Wikipedia]] Según la definición de [[https://es.wikipedia.org/wiki/Control_de_versiones|Wikipedia]]
Línea 12: Línea 17:
   * y varios etc.   * y varios etc.
  
 +  - [[ACEMU:Artículos:Artículos Técnicos:Software:GIT:Introducción]]
 +  - [[ACEMU:Artículos:Artículos Técnicos:Software:GIT:Inicializando un repositorio]]
 +  - [[ACEMU:Artículos:Artículos Técnicos:Software:GIT:Trabajando en el respositorio]]
  
-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: +
- +
-====== RESPOSITORIO CANÓNICO ====== +
-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. +
- +
-====== BRANCHING ====== +
- +
-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. +
- +
-====== STAGING ====== +
- +
-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. +
- +
-====== WORKFLOW ====== +
- +
-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:+[[:ACEMU:Artículos:Artículos Técnicos:Software|Retorno a página anterior]]
  
-  * **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". 
acemu/articulos/articulos_tecnicos/software/git.1467230476.txt.gz · Última modificación: 2016/06/29 13:01 por tabare.perez