Diferencia entre revisiones de «Git»

De Telstock Wiki
Saltar a: navegación, buscar
m
 
(No se muestran 2 ediciones intermedias de otro usuario)
Línea 12: Línea 12:
 
:*[[Estándar para documentación de Commits | Estándar para documentación de Commits  ]]
 
:*[[Estándar para documentación de Commits | Estándar para documentación de Commits  ]]
 
:*[[Proceso para hacer merge entre dos ramas | Proceso para hacer merge entre dos ramas ]]
 
:*[[Proceso para hacer merge entre dos ramas | Proceso para hacer merge entre dos ramas ]]
:*[[Proceso para hacer Squash entre dos ramas | Proceso para hacer squash entre dos ramas]]
+
:*[[Restablecer una rama | Restablecer una rama ]]
 +
 
  
 
{{warning |1=Este tipo de despliegue se realiza de forma manual actualmente, sin embargo, la idea es migrar este comportamiento para que sea administrado por [[Jenkins]] como parte de la '''integración continua''' que se va a implementar para todos los proyectos }}
 
{{warning |1=Este tipo de despliegue se realiza de forma manual actualmente, sin embargo, la idea es migrar este comportamiento para que sea administrado por [[Jenkins]] como parte de la '''integración continua''' que se va a implementar para todos los proyectos }}
Línea 18: Línea 19:
 
:*[[Desplegar cambios en servidor de Desarrollo o QA]]
 
:*[[Desplegar cambios en servidor de Desarrollo o QA]]
 
:*[[Estrategia para desplegar cambios entre ramas del servidor]]
 
:*[[Estrategia para desplegar cambios entre ramas del servidor]]
 +
:*[[Estrategia para desplegar cambios entre ramas del servidor con Squash]]

Revisión actual del 19:18 30 oct 2019

Para la gestión del código fuente de todos los proyectos de Telstock, se emplea [Git].

Se ha definido una estructura estándar a nivel de [Branches] para los repositorios de los proyectos.

La definición de la estructura de los repositorios, cómo clonar un repositorio GIT y otros estándares de uso interno se describen en las siguientes secciones:


Warning Warning: Este tipo de despliegue se realiza de forma manual actualmente, sin embargo, la idea es migrar este comportamiento para que sea administrado por Jenkins como parte de la integración continua que se va a implementar para todos los proyectos