Ciclo 3.

Semana 2 - Sesión 3

Gracias por su participación, en 5 min comenzamos

 Cuidar el
lenguaje

Mantener la
Mantener el
cámara
micrófono
encendida
en silencio

TIPS PARA Respetar la

Notificar al
instructor las CONVIVENCIA opiniones de
los demás
novedades EN AMBIENTES
DE FORMACIÓN
VIRTUAL
Pedir la Ser puntual.
palabra

Escuchar a
los demás
La pantalla del ordenador tiene que poderse orientar e inclinar. Debe situarla a unos
45cm de distancia, frente a los ojos y a su altura

No permanecer en la misma postura durante periodos prolongados.

Se debe apoyar completamente los pies en el suelo y mantener las rodillas al

mismo nivel o por encima de las caderas

Si fuera necesario, modificar adecuadamente el entorno (mobiliario, altura de los

objetos, iluminación, etc) buscando la situación más cómoda y segura para la
espalda.
Sistema de
control de Git GitLab
versiones
Mira esta imagen y dime qué piensas
Inducción a Repositorios Software y
control de versiones

El control de versiones, también conocido como "control de código fuente", es la práctica de

rastrear y gestionar los cambios en el código de software. Los sistemas de control de versiones son
herramientas de software que ayudan a los equipos de software a gestionar los cambios en el código
fuente a lo largo del tiempo.

El software de control de versiones realiza un seguimiento de todas las modificaciones en el código en

un tipo especial de base de datos. Si se comete un error, los desarrolladores pueden ir hacia atrás en el
tiempo y comparar las versiones anteriores del código para ayudar a resolver el error, al tiempo que se
minimizan las interrupciones para todos los miembros del equipo.

El control de versiones protege el código fuente tanto de las catástrofes como del
deterioro casual de los errores humanos y las consecuencias accidentales.
Inducción a Repositorios Software
Diferencia entre un servicio de alojamiento de repositorios y un
sistema de control de versiones
Es importante reconocer que los servicios de alojamiento de repositorios y los sistemas de control de versiones son
dos entidades independientes. Los sistemas de control de versiones, son las utilidades de líneas de comando de
bajo nivel que se emplean para gestionar los cambios del ciclo de vida de desarrollo de software, todo en una
colección de archivos de código fuente.

Los servicios de alojamiento de repositorios son aplicaciones web de terceros que encapsulan y mejoran
un sistema de control de versiones. Es importante resaltar que, no se puede utilizar por completo un servicio
de alojamiento de repositorios sin tener que usar un sistema de control de versiones subyacente.

En resumen, un repositorio de código es un servidor con un sistema de control de versiones,

que permite guardar todo nuestro programa, toda nuestra aplicación en un lugar seguro, y lo
hace a través de un control de versiones que permite mantener un historial de todos los
cambios que se producen.
Inducción a Repositorios Software
Ventajas de los repositorios de software
● Permite el trabajo en paralelo de dos o más usuarios de una aplicación o programa, sin que se den por válidas
versiones con elementos que puedan entrar en conflicto entre sí.

● La seguridad de un repositorio de código en un servidor es máxima, ya que este garantiza la misma mediante
diferentes métodos avanzados de ciberseguridad y la creación constante de copias de seguridad.

● Permite disponer y acceder a un historial de cambios. Cada programador tiene la obligación de señalar qué cambios
ha realizado, quién los ha llevado a cabo y también cuándo se hicieron. Esto permite un mayor control sobre cada
versión, permite corregir cambios y facilita que cada cambio ejecutado se vea como un nuevo estado.

● Facilita el entendimiento del proyecto, sus avances y el estado actual de la última versión. Algo
posible gracias a que cada pequeño cambio efectuado por un programador, debe ir acompañado
por un mensaje explicativo de la tarea realizada. Es así como se evita a los demás programadores
perder tiempo cuestionando el porqué de los cambios ejecutados. De igual manera, facilita la
corrección de errores si los hubiera o si son detectados por otro programador.
Sistema de control distribuido

Los Sistemas de Control de Versiones Distribuidos

(en adelante SCVD), no dependen necesariamente de
un servidor central para almacenar las versiones de los
ficheros del proyecto. En los SCVD, cada programador
tiene una copia local o clon del repositorio principal.
Esto quiere decir que, cada programador mantiene un
repositorio local propio que contiene todos los archivos y
metadata presente en el repositorio principal. Todos
pueden operar con su repositorio local sin ninguna
interferencia.
Sistema de control distribuido
Todos los programadores pueden actualizar sus repositorios locales con nuevos datos del servidor central con una
operación llamada ‘pull‘ y persistir cambios en el repositorio principal con una operación llamada ‘push‘ desde su
repositorio local. El hecho de clonar un repositorio entero en su propio puesto de trabajo para tener un repositorio local,
proporciona las siguientes ventajas:

● Todas las operaciones (excepto push y pull) son muy rápidas porque la herramienta sólo necesita acceder al
disco duro, no a un servidor remoto. Por tanto, no siempre se necesita conexión a internet.

● Los nuevos cambios se pueden guardar (commit) localmente sin manipular los datos del repositorio principal. Una
vez se tenga listo un conjunto de cambios, se pueden persistir (push) todos a la vez en el repositorio principal.

● Dado que cada programador tiene una copia completa del repositorio del proyecto, pueden compartir los
cambios entre sí si fuera necesario obtener un feedback antes de persistir los cambios en el repositorio
principal.

● Si el servidor central sufre algún percance en algún momento, los datos perdidos pueden ser
recuperados fácilmente desde cualquiera de los repositorios locales de los colaboradores.
GIT

Git es una herramienta software de código abierto para el

control de versiones diseñado para manejar con rapidez y
eficiencia, desde proyectos pequeños hasta proyectos muy
grandes. Adicionalmente, es una herramienta fácil de aprender,
que ocupa poco espacio y de alto rendimiento, que supera a
herramientas similares como Subversion, CVS, Perforce,
ClearCase, entre otras.
Palabras clave
Clon Clon: Se utiliza para fijar como objetivo un repositorio
existente con el fin de clonarlo o copiarlo.

Una vez que un desarrollador ha obtenido una copia de

trabajo, todas las operaciones de control de versiones se
gestionan por medio de su repositorio local.

Si un proyecto ya se ha configurado en un repositorio

central, el comando git clone es la manera más común
de que los usuarios obtengan una copia de desarrollo.
Palabras clave
Commit Commit: Se utiliza para capturar el estado de un
proyecto en ese determinado momento. Las instantáneas
de Git siempre se confirman en el repositorio local.

Git no te obliga a interactuar con el repositorio central

hasta que estés listo. Del mismo modo que el entorno de
ensayo es una zona intermedia entre el directorio de
trabajo y el historial del proyecto, el repositorio local de
cada desarrollador es una zona intermedia entre sus
contribuciones y el repositorio central.

Ese proceso NO es automático, el programador debe

ejecutar esa función cuando lo vea necesario.
Palabras clave
Branch Branch o Ramas: La creación de ramas es una función
disponible en la mayoría de los sistemas de control de
versiones modernos.

Las ramas de Git son un puntero eficaz para las

instantáneas de tus cambios. Cuando quieres añadir una
nueva función o solucionar un error, independientemente
de su tamaño, generas una nueva rama para alojar estos
cambios.

Al desarrollarlas en ramas, no solo es posible trabajar con

las dos de forma paralela, sino que también se evita que
el código dudoso se fusione con la rama main.
Palabras clave
Fork Fork o Tenedor: A diferencia de branch, el fork es otro
proyecto que se crea a partir de otro. Por ejemplo las
distribuciones de Linux.

Ese repositorio copiado será básicamente un clon del

repositorio desde el que se hace el fork, pero a partir de
entonces el fork vivirá en un espacio diferente y podrá
evolucionar de manera distinta.

Una vez hecho el fork existirán dos repositorios distintos.

Inicialmente uno era copia exacta del otro, pero a medida
que se vaya desarrollando y publicando cambios en uno u
otro repo, ambos repositorios podrán tender a ser tan
distintos como quieran cada uno de los equipos de
desarrollo que los mantengan.
Historia GIT
En el 2005, la relación entre la comunidad que desarrollaba el
kernel de Linux y la compañía que desarrollaba BitKeeper se
vino abajo y la herramienta dejó de ser ofrecida de manera
gratuita. Esto impulsó a la comunidad de desarrollo de Linux (y
en particular a Linus Torvalds, el creador de Linux) a
desarrollar su propia herramienta basada en algunas de las
lecciones que aprendieron mientras usaban BitKeeper.

VER VIDEO
GIT
A diferencia de otras herramientas que almacenan los datos como una lista de cambios basados en archivos. Git
maneja sus datos como una serie de capturas instantáneas de un sistema de pequeños archivos donde cada vez
que confirma o guarda el estado de un proyecto, Git almacena una referencia a esos archivos captados. Para ser
eficiente, si los datos no han cambiado, únicamente se establece un enlace al archivo anteriormente almacenado.

Lo importante a tener en cuenta, es que Git tiene tres estados principales en los que pueden residir sus archivos:
modificado (modified), preparado (staged) y confirmado (committed).

Modificado: significa que ha cambiado el archivo, pero aún no lo ha confirmado en su base de datos (archivo .git).

Preparado: significa que ha marcado un archivo modificado en su versión actual para pasar a su próxima captura
de confirmación, es decir, falta la confirmación (commit).

Confirmado: significa que los datos se almacenan de forma segura en su base de datos local
(archivo .git).
Características de GIT
Distribuido: Cada desarrollador tiene una copia del
proyecto en su disco local, lo que significa que no
necesitan conectarse a un servidor y/o conexión a
internet. Al ser un proyecto local pueden acceder a él y
trabajar en cualquier momento.

Cada desarrollador cuenta con un backup del proyecto,

en caso tal de que ocurriese algo con el proyecto del
programador X, los demás compañeros del proyecto
tienen una copia de respaldo y así no se pierde
información.
Características de GIT
Ramas y fusiones: Las ramas son nuevos caminos o
bifurcaciones para no comprometer a la rama principal y
mantener así su integridad y sirven para hacer pruebas y
probar algunos métodos especiales. Pero esas ramas
luego se deben volver a integrar al main, a ese proceso
se le conoce como fusión o merge.

En ese merge pueden encontrarse conflictos y es la parte

neurálgica de trabajar bajo esta modalidad.
Flujo de trabajo en GIT
Integridad de datos: Git agrega un Checksum o suma
de comprobación a cada uno de los archivos y de los
commits, de tal manera que hay la certeza y seguridad de
que cada uno de los desarrolladores tenga los mismos
datos que los demás.

Lo anterior se realiza para evitar datos corruptos o que

puedan afectar la integridad del proyecto.
GIT
Esto nos lleva a tres secciones principales de un proyecto de Git: el Directorio de Trabajo (Working Directory),
Área de Preparación (Staging Area) y Directorio de Git (.git Directory (Repository)), como se muestra en la
siguiente Figura:

Imagen tomada de https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F

staging area, and Git directory.
GIT
El Directorio de Trabajo (Working Directory), es
una comprobación única de una versión del proyecto.
Estos archivos se crean o extraen de la base de datos
comprimida en el directorio Git y se colocan en el
disco para que los utilice o modifique.
GIT
El Área de Preparación (Staging Area) es un
archivo, generalmente contenido en su directorio Git,
que almacena información sobre lo que se incluirá en
su próxima confirmación o commit. Su nombre técnico
en la jerga de Git es "index", pero la frase "staging
area" es la más empleada.
GIT
El Directorio .Git (.git Directory) es donde Git
almacena los metadatos y la base de datos de objetos
para su proyecto. Esta es la parte más importante de
Git y es lo que se copia cuando clonas un repositorio
desde otra computadora, o un repositorio remoto.
GIT
La mayoría de operaciones de Git se ejecutan en la máquina local, de tal forma que, todo el historial de su
proyecto está en la base de datos de su disco local (directorio .git), permitiendo un alto rendimiento en la
ejecución de sus funciones. Así mismo, para compartir el proyecto con otros miembros del equipo, se utilizan
repositorios remotos en plataformas de social coding como GitHub y GitLab, entre las más populares.
Flujo de trabajo normal en GIT
La mayoría de operaciones de Git se ejecutan en la máquina local, de tal forma que, todo el historial de su
proyecto está en la base de datos de su disco local (directorio .git), permitiendo un alto rendimiento en la
ejecución de sus funciones. Así mismo, para compartir el proyecto con otros miembros del equipo, se utilizan
repositorios remotos en plataformas de social coding como GitHub y GitLab, entre las más populares.
Flujo de trabajo en equipo con GIT
En equipo la cosa es un poco diferente. Tenemos la rama principal o Master, y de ahí desprendemos una rama que
se llama Dev. Desde la cual los desarrolladores harán sus aportes y trabajos a esa rama Dev.

Brench Merge

Como ya lo vimos, en el Merge pueden ocurrir problemas, para ello existe el líder de
proyecto y/o test automatizados para revisar que no existan conflictos.
Flujo de trabajo en equipo con GIT
Al final, se debe volver a tomar la rama Dev para introducirla en el Master y a producción. Si todo va Bien:
funcionará.
Descargar e instalar Git de la página oficial https://git-scm.com/

Ver video
 ● git init => Crea un repositorio Git vacío o reinicia uno existente. Básicamente genera el directorio .git con los
subdirectorios para los objetos, refs/heads, refs/tags, y plantillas (template files).
● git add -A (git add .) => Agrega todo el contenido y/o cambios, dados en el directorio, en el índice (index)
del siguiente commit.
● git commit -m “mensaje” => Registra los cambios en el repositorio. Crea un nuevo commit que contiene
el nuevo material y/o cambios presentes en el índice (index), añadiendo un mensaje que, idealmente, describe
los cambios.
● git status => Muestra toda la información de la rama actual. Esta información puede ser la siguiente: si la
rama está actualizada, si hay algo para confirmar (pull), si hay archivos en el índice (index), si hay archivos
eliminados, creados o modificados.
● git clone <url> => Clona un repositorio remoto.
* Git (2022), Git Commands, Documentation. Tomado de https://git-scm.com/docs/git#_git_commands
 ● git push origin <name-branch> => Envía los cambios al repositorio remoto, en la rama que se
especifica. Esto solo envía los cambios que han sido confirmados.
● git pull <nombre-remoto> => Recoge los cambios de un repositorio remoto e inmediatamente los aplica al
repositorio local.
● git branch => Lista, crea o elimina ramas. Ejemplos: git branch <name-branch> para crear una rama
nueva, git branch -d <name-branch> para eliminar una rama, etc.
● git checkout <name-branch> => Cambia a la rama especificada. Actualiza los archivos para que
correspondan con el árbol de trabajo de dicha rama.
● git merge <name-branch> => Combina dos o más historias de desarrollo.

* Git (2022), Git Commands, Documentation. Tomado de https://git-scm.com/docs/git#_git_commands

GRACIAS