Practico

Trabajo Práctico N.
º 3
Gestores de la
Configuración
Cátedra: Ingeniería de Software

4K9 Año 2018
Prof.: Ing. Mónica Colombo
Prof. JTP: Lic. Graciela M. Lastra
Ayudante: Ing. Matías Martínez
Integrantes:
Álvarez, Sebastián
Izquierdo, Yael
Miñan, Agustin
Monteverdi, Emiliano
Segui, Ignacio
Sevillano, Gerardo
INGENIERÍA EN SISTEMAS DE INFORMACIÓN
ING. DE SOFTWARE – COMISION 4K9 - AÑO 2018
GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Índice
Subversion 3
Manejo de versiones: 4
Control de acceso 4
Funcionamiento básico 5
Creación del repositorio 5
Agregamos un archivo 6
Creación de una copia de trabajo 7
Commit de archivos 8
Git 9
Sistema de Control de Versiones Distribuido (DVCS) 9
Fundamentos de Git 10
Manejo de Variaciones (Instantáneas) 10
Integridad 10
Estados de Archivos 10
Áreas de Git 11
¿Como usar Git? 12
Flujo de trabajo básico 12
Iniciar u obtener un repositorio 12
Inicializar el repositorio en un directorio existente: 12
Clonar un repositorio existente 12
Modificar archivos en el directorio de trabajo 12
Comprobamos el estado de los archivos 12
Añadir archivos a la Staging Area 14
Confirmar los cambios 14
Subir cambios al Repositorio Remoto 15
Ramificaciones en Git 16
¿Qué es una rama? 16
¿Como se crea una rama? 16
Confirmación de cambios en una rama 18
Fusión de ramas 19
Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 1


Diferencias entre Git y Subversion 21
Control de versiones 21
Modelado de datos 22
Usabilidad 23
Conectividad 23
Historial de cambios 24
Protección de datos 24
Tamaño de la copia de trabajo 24
HERRAMIENTAS DE INTEGRACIÓN CONTINUA 25

JENKINS 25
INSTALACIÓN Y UTILIZACIÓN DE JENKINS 26
Ventajas 31
Desventajas 31
Bibliografía 32

Subversion
Usamos el programa TortoiseSVN que es un cliente subversion.
Es un sistema de control de versiones centralizado. Tiene un único servidor central que

contiene todos los archivos versionados al que los colaboradores descargan los archivos desde
ese servidor central. Por ejemplo, todo el mundo puede saber (hasta cierto punto) en qué
están trabajando los otros colaboradores del proyecto. Los administradores tienen control
detallado de qué puede hacer cada uno y es mucho más fácil administrar un CVCS dado que
solo existe una copia general y los colaboradores solo descargan instantáneas de esa copia.
Esta configuración también tiene serias desventajas. La más obvia es el punto único de
fallo que representa el servidor central. Si cae durante una hora, entonces durante esa hora
nadie puede colaborar o guardar cambios versionados de aquello en que están trabajando. Si
el disco duro en el que se encuentra la base de datos central se corrompe, y no se han llevado
copias de seguridad adecuadamente, se pierde absolutamente todo excepto las instantáneas
locales

● Manejo de versiones:
Almacena la información con los archivos iniciales y una lista de cambios en
estos. Modela la información que se almacena como un conjunto de archivos y las
modificaciones hechas sobre cada uno de ellos a lo largo del tiempo
● Control de acceso
Tortoise maneja la concurrencia a los archivos mediante bloqueos. Se utiliza
para evitar que dos o más personas modifiquen el mismo archivo al mismo tiempo, ya
que sólo se guardarían los cambios realizados por la última persona que guardó el
cambio.
Por defecto, nada se bloquea y todo el mundo puede confirmar cambios a

cualquier archivo en cualquier momento. Los demás actualizarán sus copias de trabajo
periódicamente y los cambios en el repositorio se fusionarán con los cambios locales.
El bloqueo debe ser explícito sobre un archivo, al obtenerlo, solo este usuario
puede confirmar ese archivo. Las confirmaciones de los demás se desestimarán hasta
que quite el bloqueo. Un archivo bloqueado no puede ser modificado de ninguna
forma en el repositorio, por lo que no puede ser siquiera borrado o renombrado,
excepto por el dueño del bloqueo.
El bloqueo se asigna a un usuario específico y a una copia de trabajo como

conjunto. Significa que el usuario sólo puede hacer la confirmación desde esa copia de
trabajo a la cual fue asignado el bloqueo. Esto impide al mismo usuario de hacer un
commit del fichero bloqueado desde otra copia de trabajo.

Funcionamiento básico
Se mostrará el funcionamiento con un repositorio local usando TortoiseSVN
1. Creación del repositorio

Se crea una carpeta y luego se usa el menú contextual de windows donde se
selecciona TortoiseSVN -> Create repository here.

En esta imagen se ve como queda la estructura de carpetas del repositorio (izquierda),

y lo que ve Windows (derecha)
2. Agregamos un archivo
Se va a agregar un archivo directamente al repositorio, no desde una copia de
trabajo, sería como los archivos iniciales del repositorio.
Creamos un archivo txt y desde el repo-browser se agrega, junto con un mensaje para
la revisión.

3. Creación de una copia de trabajo

En un espacio vacío en el escritorio o en el explorador de archivos se abre el
menú contextual (botón derecho del mouse) y se selecciona “SVN Checkout…”, lo que
nos abre la siguiente ventana
Donde colocamos la url del repositorio (en este caso usamos el repositorio
local), la dirección de creación de la copia de trabajo, lo que nos deja con las siguientes
carpetas, las mismas del repositorio

4. Commit de archivos
Modificamos el archivo de texto que estaba dentro del repositorio, luego se
selecciona “SVN Commit...”, lo que permite subir al repositorio los archivos
modificados o creados, según la siguiente captura.

Allí se puede seleccionar los archivos para hacer el commit, junto con un
mensaje descriptivo que va al log de la revisión. Y así muestra la confirmación del
commit.
Git
Es un Sistema de Control de Versiones Distribuido (DVCS) diseñado por Linus Torvalds,
pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones
cuando éstas tienen un gran número de archivos. Su propósito es llevar registro de los cambios
en archivos de computadora y coordinar el trabajo que varias personas realizan sobre archivos
compartidos.
Sistema de Control de Versiones Distribuido (DVCS)

En un DVCS como lo es Git, los clientes no solo descargan la última instantánea de los
archivos, si no, que replican completamente el repositorio. De esta forma, si un servidor muere
cualquiera de los repositorios de los clientes pueden copiarse en el servidor para restaurarlo,
Cada vez que se descarga una instantánea se hace una copia completa de todos los datos.
Se puede utilizar para tener varios repositorios con los que trabajar, Esto permite
establecer varios flujos de trabajo que no son posibles en sistemas centralizados.

Fundamentos de Git
● Manejo de Variaciones (Instantáneas)
Git modela sus datos como un conjunto de instantáneas . Cada vez que se
confirma un cambio, o se guarda el estado de un proyecto, Git realiza una “foto” del
aspecto de todos sus archivos en ese momento, y guarda una referencia a esa
instantánea. Si el archivo no se a modificado, Git no almacena el archivo nuevamente,
sino, que genera un enlace al archivo anterior.
Una instantánea además contiene metadatos del autor, mesajes explicativos y
punteros a las confirmaciones que son padres directos de esta.
● Integridad
Antes de almacenar algo en Git es verificado mediante una suma de
comprobación, y es identificado por dicha suma. Esto garantiza que no se pierda
información durante su transmisión o sufrir corrupción de archivos sin que Git lo
detecte.
El mecanismo utilizado por Git es hash SHA-1 (Cadena de 40 caracteres
hexadecimales) y tiene un aspecto similar a este:
24b9da6552252987aa493b52f8696cd6d3b00373
● Estados de Archivos
Git posee 3 estados principales en los que pueden encontrarse los archivos:
○ Confirmado (Committed): Significa que los datos están guardados de manera
segura en la base de datos local (git directory).
○ Modificado (Modified): Significa que el archivo se a modificado pero que no
ha sido confirmado en la base de datos local.


○ Preparado (Staged): Significa que se ha marcado el archivo modificado en la
versión actual para que vaya en el próximo Commit
● Áreas de Git
○ Directorio de Git (repositorio): Es donde Git almacena los metadatos y la base
de datos del proyecto, es lo que se copia cuando se clona un repositorio.
○ Directorio de trabajo (Working Directory): Es una copia de una versión del
proyecto. Estos archivos se sacan de la base de datos en el directorio de Git, y
se colocan en el disco para ser usados o modificados.
○ Área de preparación (Staging Area): Es un archivo, generalmente contenido
en el directorio de Git, que almacena información acerca de lo que se va a
mover al directorio de Git en el próximo commit.

¿Como usar Git?

Flujo de trabajo básico
1. Iniciar u obtener un repositorio

Podemos obtener un repositorio de dos formas:
○ Inicializar el repositorio en un directorio existente:
Ubicados en el directorio del proyecto, se debe utilizar el comando git

init. Esto creará un nuevo subdirectorio en el proyecto llamado .git que
contiene los archivos necesarios del repositorio
○ Clonar un repositorio existente

Se obtiene un copia de un repositorio existente, de forma remota o
local. Se utiliza el comando git clone [url] en el directorio donde se desea
copiar el repositorio.
2. Modificar archivos en el directorio de trabajo
3. Comprobamos el estado de los archivos

Para comprobar el estado de los archivos dentro del proyecto se utiliza el
comando git status, Este comando verifica el estado de los archivos e informa si no
hay nada a lo que se deba hacer un commit.


Un archivo del directorio de trabajo puede estar en uno de estos dos estados:
● Tracked: Son aquellos archivos que existían en la última
instantánea, pueden estar modificados, en el Staged Área y sin
modificar.
● Untracked: Son todos los demás archivos, cualquiera que no
estuviese en la última instantánea.
4. Añadir archivos a la Staging Area

Luego de realizar modificaciones en el proyecto, debemos preparar los
archivos modificados o nuevos a la Staging Area, esto se logra utilizando el comando
git add [archivo].
5. Confirmar los cambios

Una vez añadidos los archivos modificados a la Staging Area, debemos
confirmar los cambios utilizando el comando git commit, Este comando toma los
archivos de la Staging Area y los mueve al Repositorio Local. Junto con este comando
se suele añadir un mensaje para explicar el commit.

6. Subir cambios al Repositorio Remoto

Si se está trabajando con un repositorio remoto y se desean aplicar los cambios
en este, el comando que permite realizar esto es git push [nombre-remoto]
[nombre-rama]. En este caso vamos a enviar los cambios de la master branch a
nuestro servidor origen.
Master Branch (Rama Maestra): Es la rama en la que estamos trabajando, que
por defecto.

Ramificaciones en Git
¿Qué es una rama?
Una rama es un puntero móvil que apunta a una instantánea. La rama por defecto de
Git es la rama master, esta se genera con la primera confirmación de cambios que realicemos.
La rama master apuntará siempre a la última instantánea realizada.
(rama master con su historial de confirmaciones (commits)).
¿Como se crea una rama?

Para crear una nueva rama en el proyecto se utiliza el comando git branch
[nombre-rama], lo que hace este comando es crear un nuevo puntero móvil.
(La rama en verde es la rama en las que se está trabajando en el momento de usar el comando)

Git utiliza un puntero especial llamado HEAD que apunta a la rama local en la que
estés trabajando en ese momento, en el caso de la imagen anterior, la rama master.
Para cambiar de rama se utiliza el comando git checkout [nombre-rama], que modifica
el puntero del HEAD para apuntar a la rama solicitada.

Confirmación de cambios en una rama

La confirmación de cambios en una rama se realiza utilizando el comando git commit
en la rama que se desea confirmar los cambios.
Si realizamos un commit en la rama master y otro en la rama testing, generamos que
las cada rama pase a ser independiente como muestra en la imagen.

Fusión de ramas
Se utiliza el comando git merge [nombre-rama], el comando origina que Git realiza
una fusión a tres bandas, utilizando las dos instantáneas apuntadas por el extremo de cada una
de las ramas y el ancestro en común de estas dos.

Git crea una nueva instantánea resultante de la fusión a tres bandas y crea una nueva
confirmación de cambios (commit) que apunte a ella. Este proceso se llama fusión confirmada
y se diferencia en que tiene más de un padre.

Si existe algún conflicto entre las ramas a fusionar, Git muestra un mensaje advirtiendo
de los archivos que generaron conflictos para que se arreglen de forma manual, una vez
modificados se deben confirmar los cambios realizados y realizar la fusión de ramas
nuevamente.
Diferencias entre Git y Subversion
● Control de versiones
El control de versiones distribuido toma un enfoque entre iguales, opuesto al
enfoque de cliente-servidor de los sistemas centralizados. En lugar de un único
repositorio central en el cual los clientes se sincronizan (centralizado), la copia local del
código base de cada peer es un repositorio completo (distribuido). El control de
versiones distribuido sincroniza los repositorios intercambiando ajustes entre iguales.

● Modelado de datos
Git modela sus datos como un conjunto de instantáneas . Cada vez que se confirma un
cambio, o se guarda el estado de un proyecto, Git realiza una “foto” del aspecto de todos sus
archivos en ese momento, los archivos modificados se vuelven a copiar mientras que en los
archivos no modificados se crea un puntero al archivo en la instantánea más reciente; y guarda
una referencia a esa instantánea en la confirmación.

Subversion almacena la información con los archivos iniciales y una lista de cambios en
estos. Modela la información que se almacena como un conjunto de archivos y las
modificaciones hechas sobre cada uno de ellos a lo largo del tiempo.
● Usabilidad
SVN tiene más amplitud de plugins para distintas IDE, y a su vez es más amigable al
usuario. Por otro lado, git es más complejo lo que conlleva una interfaz menos amigable al
usuario que svn.
● Conectividad
SVN necesita conectividad permanente para cada operación, ya que no tenemos toda
la información en nuestra máquina. Git, al distribuir todo el repositorio a cada colaborador,
disminuye la necesidad de conectividad a sólo cuando se va a acceder al servidor remoto ya
sea para recibir o enviar datos. Este punto también afecta a la velocidad, al no haber
conectividad permanente, git es más rápido que svn para operaciones comunes.

● Historial de cambios
El historial de cambios de git es completo, tanto en el repositorio como en las copias
de trabajo locales, pero en svn el repositorio completo posee el historial y las copias de trabajo
solo tienen la versión más reciente
● Protección de datos
En la protección de datos ante pérdida, git tiene la solución al tener todo el repositorio
en cada copia de trabajo, por ende cada colaborador tiene un backup ante cualquier
catástrofe. En cambio bajo svn hay que poner énfasis en un backup del servidor central
● Tamaño de la copia de trabajo

La clonación inicial en git de un repositorio es más lenta comparada a subversion,
porque todas las ramas y el historial de revisiones son copiados. Esto puede ser significativo si
la velocidad de la red es lenta y el tamaño del repositorio es lo suficientemente grande.
Mientras, subversión sólo descarga una instancia de una revisión, por lo que el tamaño es
considerablemente menos

HERRAMIENTAS DE INTEGRACIÓN CONTINUA

La Integración continua, como la hemos trabajado en este práctico, supone un apoyo a
los gestores de configuración. En algunos aspectos utiliza la misma metodología y
procedimientos agregando algunos aspectos extra que veremos más adelante, pero para
entender un poco más sobre el tema buscamos información al respecto:
La integración continua (continuous integration en inglés) es un modelo informático

propuesto inicialmente por Martin Fowler que consiste en hacer integraciones automáticas de
un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes. Entendemos
por integración la compilación y ejecución de pruebas de todo un proyecto.
El proceso suele ser: cada cierto tiempo (horas), descargarse las fuentes desde el
control de versiones (por ejemplo CVS, Git, Subversion, Mercurial o Microsoft Visual
SourceSafe) compilarlo, ejecutar pruebas y generar informes.
Para esto suelen utilizarse aplicaciones como Solano CI,Bamboo,Pipeline, Apache

Continuum, Hudson, Jenkins, GoCD, CruiseControl o Anthill (para proyectos Java) o
CruiseControl.Net, Team Foundation Build para .Net, que se encargan de controlar las
ejecuciones, apoyadas en otras herramientas como Ant o Maven (también para proyectos
Java), o Nant o MSBUILD (para .Net) que se encargan de realizar las compilaciones, ejecutar las
pruebas y realizar los informes.
A menudo la integración continua está asociada con las metodologías de programación

extrema y desarrollo ágil.
A partir de esto decidimos probar la herramienta Jenkins para integración continua.
JENKINS
Jenkins es un servidor de integración continua que integra y verifica el código fuente y
genera un ejecutable (esto es llamado build y es totalmente automatizado). Esto permite
generar pruebas y hacer un control de calidad del código para detectar errores lo antes
posible.
Jenkins trabaja con tareas, donde se detalla qué hacer en un build. Un claro ejemplo
sería el programar la revisión continua cada cierto tiempo de un repositorio git de control de
versiones, y al encontrar un cambio de versión compilar y ejecutar pruebas. Si surgiera un
error Jenkins permite notificar a los integrantes ya sea al desarrollador que ha actualizado la
version nueva, a su supervisor, a un tester o a cualquier miembro del equipo al que fuera
importante notificar, esto se puede realizar por mail o cualquier otro medio.


¿Qué sucede si el build es correcto y no existen errores? Todo está en cómo
configuremos Jenkins siendo la opción más lógica la integración del código fuente con la nueva
versión y posteriormente subir el mismo al repositorio de gestor de versiones.
En palabras más amenas podemos decir que Jenkins es un Supervisor automatizado, si

hacemos mal nuestro trabajo nos advierte (¿y nos regaña?) y si no existen errores aprueba el
trabajo y lo integra a las versiones de forma definitiva.
Jenkins nos ofrece una herramienta de enlace durante todo el proceso de desarrollo.
Desde Jenkins podemos obtener métricas de calidad y ver resultados de test, generar y
visualizar documentación del proyecto e incluso extraer la version mas estable del software
para ser probado o para enviarlo a otras áreas como preproducción o producción (donde
queremos que termine nuestro código).
INSTALACIÓN Y UTILIZACIÓN DE JENKINS
Para trabajar con esta bonita herramienta partimos de los ejercicios anteriores donde
utilizamos un repositorio Git para gestionar configuración y versiones. Este repositorio será
nuestra punto de entrada de COMMITS o modificaciones por parte de “desarrolladores”. De
esta manera vinculamos estas dos herramientas e integraremos conocimientos.
Además del gestor de versiones necesitamos tener todo lo necesario para realizar la
build (ejecutable), tanto el código fuente como las librerías, los scripts de test, etc.
Para la correcta utilización de Jenkins tenemos que tener instalado el gestor de

versiones Git, Apache-maven y el mismo Jenkins. Una vez instalamos Jenkins ingresamos a
través de la dirección http://localhost:8080/ lo que nos muestra una interfaz de
configuraciones. Antes de ponernos manos a la obra tenemos que instalar los plugins
necesarios para vincular Jenkins con Git, para esto Jenkins nos da varias opciones y basta con ir
tildando los plugins deseados.

A continuación crearemos un nuevo proyecto en Jenkins. Configuramos todo para que

pueda conectarse a nuestro repositorio https://github.com/WelowID/IngSwTP3
y configuramos el build de las tareas a realizar. Haremos un validate para verificar que el
proyecto es válido y contiene todo lo necesario y haremos un compile para compilar y rever los
cambios. Configuraremos la ejecución de estas tareas cada 3 minutos.




Luego haremos una prueba agregando un archivo llamado “PruebaJenkins.txt”.
Se puede observar los detalles de la tarea una vez terminada, donde vemos los
recientes cambios, el usuario que los realizó y el ID del commit.


A partir de la información y la comprensión del tema que conseguimos no solo leyendo
la información sobre el tema sino “ensuciandonos las manos” podemos enumerar algunas
ventajas y desventajas de esta herramienta:
Ventajas
Control periódico de la evolución del proyecto, modificaciones y nuevas versiones.
Automatización de pruebas y las build.
Acceso rápido a un historial completo de cambios y estados anteriores del proyecto
Gestión intuitiva de errores a través de la automatización de pruebas y las gestión de cambios.
Desventajas
Todos los involucrados deben ser ordenados y mantener una constancia en la documentación
de cambios.
Para mayor utilidad de la herramienta es necesario un conocimiento profundo que no todos
los usuarios de la misma pueden tener.
Bibliografía
● https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones/
● https://git-scm.com/book/es/v2/Fundamentos-de-Git-Obteniendo-un-repositorio-Git/
● https://tortoisesvn.net/docs/release/TortoiseSVN_es/index.html
● https://es.wikipedia.org/wiki/Control_de_versiones_distribuido
● https://jenkins.io/doc/
● https://es.wikipedia.org/wiki/Integracion_continua/

Practico

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Practico

Cargado por

Copyright:

Formatos disponibles

Trabajo Práctico N.

Cátedra: Ingeniería de Software

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 1

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

HERRAMIENTAS DE INTEGRACIÓN CONTINUA 25

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 2

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Es un sistema de control de versiones centralizado. Tiene un único servidor central que

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 3

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Por defecto, nada se bloquea y todo el mundo puede confirmar cambios a

El bloqueo se asigna a un usuario específico y a una copia de trabajo como

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 4

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

1. Creación del repositorio

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 5

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

En esta imagen se ve como queda la estructura de carpetas del repositorio (izquierda),

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 6

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

3. Creación de una copia de trabajo

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 7

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 8

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Sistema de Control de Versiones Distribuido (DVCS)

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 9

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 10

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 11

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

¿Como usar Git?

1. Iniciar u obtener un repositorio

○ Inicializar el repositorio en un directorio existente:

Ubicados en el directorio del proyecto, se debe utilizar el comando ​git

○ Clonar un repositorio existente

2. Modificar archivos en el directorio de trabajo

3. Comprobamos el estado de los archivos

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 12

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 13

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

4. Añadir archivos a la Staging Area

5. Confirmar los cambios

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 14

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

6. Subir cambios al Repositorio Remoto

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 15

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

(rama master con su historial de confirmaciones (commits)).

¿Como se crea una rama?

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 16

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 17

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Confirmación de cambios en una rama

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 18

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 19

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Álvarez– Izquierdo– Miñan– Monteverdi– Segui– Sevillano 20

GUÍA DE TRABAJO N.º 3 – Gestores de la Configuración

Ubicados en el directorio del proyecto, se debe utilizar el comando git