Esta clase va a ser

grabada
Clase 12. JAVA INICIAL

Git
Temario

11 12 13

Spring boot – Rest GIT Invocar un servicio

– Postman II rest externo

✓ Arquitectura de 3 ✓ Versionador ✓ Consumir datos de

capas de código un REST
✓ Configuraciones ✓ GIT ✓ RestTemplate
✓ Paso a paso ✓ Request - response
Objetivos de la clase

Conocer y utilizar un versionador

de código
 MAPA DE CONCEPTOS

Local

Versionador de
código Centralizado

GIT

Distribuido
¿Qué es un versionador
de código?
Version Control System
(VCS)
Un versionador de código es una herramienta que
realiza el control de cambios en los archivos de un
programa.
El sistema de control de versiones registra los cambios
realizados en un archivo o conjunto de archivos a lo
largo del tiempo, de modo que se pueda recuperar
versiones específicas más adelante.
En este curso vamos a utilizar el control de versiones
para archivos .java pero esta herramienta permite
versionar casi todos los tipos de archivos que tengamos
en nuestra computadora, ej: excel, doc, etc.
Sistema de Control de
Versiones Locales
¿Cómo manejamos las
versiones actualmente?
Aunque no nos demos cuenta, cada uno de Este método es muy común porque es muy
nosotros seguramente ha implementado un sencillo, pero también es tremendamente
sistema de control de versiones casero. propenso a errores. Es fácil olvidar qué
directorio usamos y guardar accidentalmente
Nuestro “VCS Casero” consiste en copiar los en el archivo equivocado o sobrescribir
archivos a otro directorio (posiblemente archivos que no querías.
indicando la fecha y hora en que lo hicieron.
Ej: ProyectoFinal2022-02-01_12-23).
¿Qué problemas tenemos con
este “VCS Casero”?
Supongamos que el proyecto final se puede Para resolver este problema un encargado
realizar en equipo, los miembros del equipo por equipo debería enviar una copia
no pueden acceder fácilmente a nuestra actualizada a cada integrante, luego recibir
computadora para obtener una copia que los cambios de cada uno, integrar los
tienen que modificar y posteriormente cambios y versionar.
versionarla a mano. Una práctica inviable en proyectos de
desarrollo (también para este curso)
Sistema de Control de
Versiones Centralizado
Sistema de Control de
Versiones Centralizado
Para solucionar el problema planteado
anteriormente se desarrolló el Sistema de
Control de Versiones Centralizado (CVSC).

Estos sistemas tienen un único servidor que

contiene todos los archivos versionados y
varios clientes que descargan los archivos
desde ese lugar central.

Este ha sido el estándar para el control de

versiones por muchos años.
Fuente: Htown tech
Ventajas del sistema
centralizado
✓ Todas las personas saben hasta cierto
punto en que están trabajando los otros
colaboradores del proyecto.

✓ Los administradores tienen control

detallado sobre qué puede hacer cada
usuario.
Desventajas del
sistema centralizado
✓ La más obvia es el único punto de fallo ✓ Si el disco duro en el que se
que representa el servidor centralizado. encuentra la base de datos central
se corrompe, y no se han realizado
copias de seguridad
✓ Si ese servidor se cae durante una hora, adecuadamente, se perderá toda la
entonces durante esa hora nadie podrá información del proyecto, con
colaborar o guardar cambios en excepción de las copias
archivos en los que hayan estado instantáneas que las personas
trabajando. tengan en sus máquinas locales.
Sistema de Control de
Versiones Distribuido
Sistema de Control de
Versiones Distribuido
Los sistemas de Control de Versiones
Distribuidos (DVCS) ofrecen soluciones para
los problemas que planteamos en los
sistemas anteriores.

En un DVCS (como Git), los clientes no solo

descargan la última copia instantánea de los
archivos, sino que se replica completamente
el repositorio.
Sistema de Control de Versiones
Distribuido
Ventajas de uso del
sistema distribuido
✓ Muchos de estos sistemas se
encargan de manejar numerosos
✓ Si un servidor deja de funcionar y estos repositorios remotos con los cuales
sistemas estaban colaborando a través pueden trabajar, de tal forma que
de él, cualquiera de los repositorios puedes colaborar simultáneamente
disponibles en los clientes puede ser con diferentes grupos de personas
copiado al servidor con el fin de en distintas maneras dentro del
restaurarlo. mismo proyecto.

✓ Cada clon es realmente una copia ✓ Esto permite establecer varios flujos
completa de todos los datos. de trabajo que no son posibles en
sistemas centralizados, como pueden
ser los modelos jerárquicos.
Importancia de un
versionador
✓ Realizar un seguimiento de los cambios.
✓ Comparar cambios a lo largo del
tiempo
✓ Regresar a versiones anteriores de los
archivos.
✓ Ver quién modificó por última vez
algo que pueda estar causando
✓ Regresar a una versión anterior del problemas, ver quién introdujo un
proyecto completo problema y cuándo.
Importancia de un
versionador
REEMPLAZAR
Usar un VCS nos brinda una funcionalidad muy
POR IMAGEN
importante a los desarrolladores, porque si arruinamos o
perdemos archivos, será posible recuperarlos fácilmente.
Fuente: Centralizado vs Distribuido | Ytimg
 CUADRO COMPARATIVO

Sistema de control centralizado Sistema de control distribuido

El servidor le provee el último código a la máquina La base del código es espejada en la pc de cada
desarrollador
No hay repositorios locales Hay repositorios locales

Funciona relativamente más lento Trabaja más rápido

Siempre requiere conectividad a internet Se puede trabajar sin conexión a internet

Para comprimir, considera a la columna entera Considera columnas totales así como parciales

Foco en sincronizar, trackear y realizar el back-up Se centra en compartir cambios

de los archivos

Una falla en el servidor central finaliza todas las Una falla en el servidor principal no afecta el
versiones rendimiento
 Para pensar
¿Qué diferencias existen entre los sistemas de
control de versiones centralizados y los
distribuidos?

Contestar en el chat de Zoom

 ☕
Break
¡10 minutos y volvemos!
GIT
 Definición oficial
Git es un sistema de control de versiones
distribuido gratuito y de código abierto
diseñado para manejar todo, desde
proyectos pequeños hasta proyectos muy
grandes, con rapidez y eficiencia.

Git es fácil de aprender y ocupa poco

espacio con un rendimiento ultrarrápido.
Supera a las herramientas de SCM como
Subversion, CVS, Perforce y ClearCase con
características como ramas locales, staging
áreas y múltiples flujos de trabajo.

Fuente: GIT
Línea de Comandos
La línea de comandos es el único lugar en
donde puedes ejecutar todos los comandos
de Git.
Todos los alumnos tendrán las herramientas
de línea de comandos instaladas y
disponibles.
Descargar la aplicación del sitio oficial de GIT
Para cada sistema operativo disponible tiene
el manual de instalación.
Instalación
Instalación
para windows
Instalación
para macOS
Instalación
para Linux
Parte I REEMPLAZAR
POR IMAGEN
Instalación
para Linux
Parte II REEMPLAZAR
POR IMAGEN
Configuración
Paso a paso
Momento 1 - Identidad

Momento 2 Confirmación de la configuración

1 - Identidad
Establecer tu nombre de usuario y dirección $ git config --global user.name "John Doe"
de correo electrónico. Esto es importante
porque los "commits" de Git usan esta $ git config --global user.email [email protected]
información, y es introducida de manera
inmutable en los commits
2 - Confirmación de la
configuración
Ejecutar el comando git config --list
Obtener un repositorio
GIT
Hay dos maneras

1 2
Momento 1 Momento 2

Tomar un proyecto o Clonar un repositorio

directorio existente e existente en Git
importarlo en Git. desde otro servidor.
1 Tomar un proyecto o directorio
existente e importarlo en Git.
A. Ir al directorio donde está el proyecto B Ejecutar el comando git init
que queremos empezar a versionar
● Esto crea un subdirectorio nuevo
llamado .git, el cual contiene todos los
archivos necesarios del repositorio –
un esqueleto de un repositorio de Git
2 Clonar un repositorio existente
en Git desde otro servidor.
A. La clonación de un proyecto Git que se B Cada versión de cada archivo de la
encuentra en otro servidor se realiza historia del proyecto es descargada por
con el comando git clone <<URL defecto cuando se ejecuta el comando
SERVIDOR GIT>> git clone

Esta forma la vamos a ver en detalle en el ejemplo en vivo

Guardar cambios en el
repositorio
Guardar cambios en el
repositorio
Tenemos un repositorio Git y un checkout o
copia de trabajo de los archivos del proyecto.

El siguiente paso es realizar algunos cambios

y confirmar snapshots de esos cambios en el
repositorio cada vez que el proyecto alcance
un estado que quieras conservar.

Cada archivo del repositorio puede tener dos

estados: tracked u untracked.
Los archivos tracked son todos aquellos
archivos que estaban en el último snapshot
del proyecto; pueden ser archivos sin
modificar, modificados o preparados.

Los archivos untracked son todos los demás

- cualquier otro archivo en el directorio de
trabajo que no estaba en el último snapshot y
que no está en el área de preparación
(staging area).
Cuando se clona por primera vez un
repositorio, todos esos archivos estarán
tracked y sin modificar pues se acaban de
“bajar del servidor” y aún no han sido
editados.

Mientras se editan los archivos, Git los ve

como modificados, pues han sido cambiados
desde su último commit.

Luego se preparan (stage) estos archivos

modificados y finalmente se confirman
(commit) todos los cambios en stage.

La sección de guardado la vamos a ver en detalle en el ejemplo en vivo.

 Ciclo de vida

Fuente: Programmerclick
 Chequeando el estado
La herramienta principal para determinar qué ✓ Esto significa que tenemos un directorio
archivos están en qué estado es el comando de trabajo limpio, es decir que no hay
git status. archivos trackeados que estén
modificados.
Si tenemos este mensaje:
$ git status ✓ Git no encuentra archivos untracked.
On branch master
Your branch is up-to-date with ✓ El comando nos indica en cuál rama
'origin/master'. estás y nos informa que no ha variado
nothing to commit, working tree con respecto a la misma rama en el
clean servidor.
 Agregando nuevos archivos
Supongamos que agregamos el archivo Para Git, untracked son los archivos que no
CoderHouse.md a nuestro proyecto, cómo estaban en el snapshot(commit) anterior y
este archivo es nuevo si ejecutamos el que aún no están estado stage.
comando git status
Podemos ver que el archivo CoderHouse.md
está untracked porque se encuentra dentro
del listado de untracked files.
Agregando nuevos archivos
Para que un archivo nuevo cambie de estado Se dice que esta staged porque se
untracked a tracked se debe ejecutar el encuentra dentro del listado de
comando git add <<NOMBRE ARCHIVO>>. archivos “Changes to be committed”
Si volvemos a ver el estado nos encontramos
que el archivo esta tracked y en stage listo
para hacer commit
Stagear archivos modificados
Al archivo que acabamos de crear, modificar y stagear,
ahora lo vamos a modificar y vamos a ver nuevamente su
status.
Stagear archivos modificados

El archivo “CoderHouse.md” aparece en el Para stagearlo, hay que ejecutar el comando

listado “Changes not staged for commit” lo git add.
que significa que existe un archivo tracked
que ha sido modificado en el directorio de git add es un comando que cumple varios
trabajo pero que aún no está en stage. propósitos:

✓ Para empezar a rastrear archivos

nuevos

✓ Stage archivos
Stagear archivos modificados

Importante notar que el mismo archivo está ¿Por qué? Cuando se ejecuta git add, Git
en dos estados distintos: poné el archivo en Stage, si realizamos un
✓ Staged commit ahora sólo se incluirá la versión del
✓ Unstaged archivo que está en Stage y quedará en
nuestro working copy la versión modificada.

Si queremos commitear esa versión también

debemos hacer el ciclo nuevamente.
 Comiteando cambios
Tenemos el staging area lista, ahora podemos Para confirmar(comitear) nuestros cambio se
confirmar(commit) los cambios. usa el comando
git commit -m “mensaje”
Importante: que cualquier cosa que no esté
staged (cualquier archivo que se haya creado
o modificado y que no se haya agregado con
git add desde su edición )no será confirmado
(comiteado). Se mantendrán como archivos
modificados.
Comiteando cambios

Tenemos nuestra primera confirmación Importante: el commit guarda un snapshot de

(commit) la staging area.
Podemos ver que la confirmación nos develve Todo lo que no esté stageado sigue allí
una salida descriptiva: modificado; podemos hacer un nuevo commit
✓ indica cuál rama hemos confirmado para añadirlo a tu historial.
(master) Cada vez que hacemos un commit, se guarda
✓ Checksum SHA-1 tiene el commit una instantánea (snapshot) del proyecto a la
(b0eaadd), cual podemos usar para comparar o volver a
✓ Cuántos archivos han cambiado y ella.
estadísticas sobre las líneas añadidas y
eliminadas en el commit.
 Comiteando cambios

En la imagen podemos ver cómo se relacionan los REEMPLAZAR

comandos y las áreas de trabajo POR IMAGEN
 Ejemplo en vivo

Vamos a crear una cuenta en Gitlab, crear un

repositorio y subir un mini proyecto
Creación de la cuenta
en GitLab
Paso a paso
Momento 1 Registrarse en about.gitlab.com

Momento 2 Crear un proyecto

Momento 3 Crear desde template

Momento 4 Elegir opción Spring

Momento 5 Colocar nombre y descripción

Momento 6 Confirmación de proyecto

Momento 1 - Registración
Ir al sitio about.gitlab.com

Clickear en el ícono de la
cuenta y registrarse
Momento 2 - Creación proyecto

Se elige la opción “Create

a project”
Momento 3 - Creación desde
template

Se elige la opción “Create

from template”
Momento 4 - Spring
Se elige la opción “Spring”
Momento 5 - Nombre y
descripción
Se elige un nombre y una
descripción
Momento 6 - Confirmación
Confirmación de la
creación del proyecto
Clonación del proyecto
Paso a paso
Momento 1 Obtener la URL

Momento 2 Abrir terminal

Momento 3 Ejecutar comando

Momento 4 Importar proyecto

Momento 1 - Obtener URL

Obtenemos la URL para

clonar el proyecto
usando https
Momento 2 - Abrir terminal
Abrimos una terminal y ejecutamos el comando:
git clone <<URL OBTENIDA>>
✓ Ingresamos el usuario y la contraseña
Momento 3 - Ejecutar comando
Entramos al proyecto clonado ejecutando el comando: Verificamos que el proyecto fue clonado y
cd primerproyectocoderhousejavainicial estamos trabajando en la rama master
Momento 4 - Importar el proyecto
Abrimos el IDE de nuestro agrado e
importamos el proyecto desde el
directorio donde fue clonado
Modificación y subida
de cambios
Paso a paso
Momento 1 Modificar mensaje

Momento 2 Actualizar modificación

Momento 3 Agregar cambio

Momento 4 Commit del cambio

Momento 5 Push del repo local

Momento 6 Verificación
Momento 1 - Cambiar mensaje
Vamos nuevamente a la consola para @SpringBootApplication
@RestController
ver que GIT nos indica que tenemos public class DemoApplication {
un archivo modificado. Usamos el
comando git status @GetMapping("/")
String home() {
return "Coder House";
}

public static void main(String[] args) {

SpringApplication.run(DemoApplication.class, args);
}
}
Momento 2 - Actualizar
modificación
Vamos nuevamente a la consola para
ver que GIT nos indica que tenemos
un archivo modificado. Usamos el
comando git status

Git nos dice que tenemos un cambio

para agregar
Momento 3 - Agregar cambio

Primero agregamos el archivo

modificado con el comando: git add .
Y luego volvemos a consultar el estado
con el comando: git status

Ahora git nos dice que tenemos un

archivo para hacer commit
Momento 4 - Commit del cambio
Hacemos commit del cambio con el comando: git
commit -m “mensaje”

Git nos indica que el cambio fue comiteado y

está asociado al ID 507a821.
Si consultamos el status vemos que nuestro
branch master local está adelantado en 1 commit
respecto del branch remoto.
Nos sugiere pushear los cambios
Momento 5 - Push del repo local
Hacemos push del repo local con el comando: Git nos confirma que los cambios locales fueron
git push pusheado la repositorio remoto
Momento 6 - Verificación
Cómo último paso para verificar que los Podemos verificar dos cosas:
cambios están subidos al repo remoto, ✓ La más importante es que el ID del commit
accedemos a GitLab y verificamos que el es el mismo que el que tenemos en
proyecto original tiene un commit nuestro local
✓ Que el mensaje que definimos es el
aparece en la descripción de GitLab
 Actividad en clase

¡Llevemos lo visto hasta el momento a la

acción!
Les proponemos que puedan realizar la
siguiente actividad.

Duración: 20 minutos
ABM Entidad Cliente v2
 ACTIVIDAD EN CLASE

ABM Entidad
Cliente v2
A partir de actividad en clase desarrollada en la clase
8 se pide:

Agregar la capa service

Cuando se busca un cliente por nombre que no exista
el mensaje de respuesta debe ser "La búsqueda no dio
resultados"

El desafío tiene un tiempo estimado de 20 minutos

 Segunda entrega
de tu Proyecto final
Consiste en tomar el proyecto de la primera entrega para
convertirlo en un proyecto Spring Boot el cual utilice alguna
librería de jpa para poder conectarse a la base de datos.
 ENTREGA DEL PROYECTO FINAL

Segunda entrega
Objetivos generales Objetivos específicos
✓ tomar el proyecto de la primera entrega para ✓ Cada entidad definida en la primera
convertirlo en un proyecto Spring Boot entrega debe usar la arquitectura de 3
✓ Utilizar alguna librería de jpa para poder capas para ser manipulada.
conectarse a la base de datos. ✓ Se espera que las modificaciones se
realicen en cascada.
✓ Generar los scripts de inicialización de
datos para las tablas creadas en la
primera entrega
 ENTREGA DEL PROYECTO FINAL

Segunda entrega
Se debe entregar Sugerencias
✓ un archivo en formato zip o rar
✓ Se sugiere que el código esté bien
✓ Los scripts de base de datos para la
documentado.
inicialización del proyecto
✓ Cada entidad debe tener 3 capas,
Formato Controller, Service, Repository
✓ Proyecto Java en formato jar ejecutable
respetando la siguiente nomenclatura
“FacturacionSegundaEntrega+Apellido”.
¿Preguntas?
Opina y valora
esta clase
 Resumen
de la clase hoy
✓ Versionador de código
✓ GIT
✓ Paso a paso de GIT
Encuesta
sobre esta clase
Por encuestas de Zoom

¡Terminamos la clase!

Cuéntanos qué temas te resultaron más complejos de

entender. Puedes elegir más de uno. Vamos a retomar
aquellos temas que resultaron de mayor dificultad en el
próximo AfterClass.
Muchas gracias.